Actions
action #124035
closedcoordination #119836: [epic] Convert YAML schedules for YaST to be based on YAML default files
Create default yaml if applies for aarch64 and adapt test suites to use it if needed in YaST group
Start date:
2023-02-07
Due date:
% Done:
0%
Estimated time:
Description
Observation¶
We will create a default file for aarch64 if needed (if it is different from x86_64) and adapt the test suite for aarch to use it.
We need update all the interactive installation for aarch64 and see if we can reuse the same done for x86_64 64 bit.
Acceptance criteria¶
AC1: Create default yaml file if needed
AC2: Create new aarch64 yaml files where applies
Suggestions¶
- Take inspiration from other tasks done in Epic where this task belongs.
Updated by JERiveraMoya almost 2 years ago
- Subject changed from Modify existing default yaml file for aarch and adapt test suites to use it in YaST group to Create default yaml if applies for aarch64 and adapt test suites to use it if needed n YaST group
Updated by JERiveraMoya over 1 year ago
- Tags set to qe-yam-refinement
- Target version deleted (
Current)
Updated by JERiveraMoya over 1 year ago
- Tags deleted (
qe-yam-refinement) - Target version set to Current
Updated by tinawang123 over 1 year ago
- Status changed from Workable to In Progress
Updated by tinawang123 over 1 year ago
Updated by JERiveraMoya over 1 year ago
- Subject changed from Create default yaml if applies for aarch64 and adapt test suites to use it if needed n YaST group to Create default yaml if applies for aarch64 and adapt test suites to use it if needed in YaST group
Updated by JERiveraMoya over 1 year ago
My suggestion to resolve this ticket is the following:
- Address all the comment in current PR.
- Create MR and review it.
- Merge both PR and MR
- Re-trigger in YaST job group the whole architecture. We don't want to show there any failure that wasn't there in GM, for us a reference and for other stackholders is also some place to check where our work is quite visible, so we don't want to pollute. In that case once you re-trigger the whole architecture we need remove the failures produced by infra issues or some missing configuration in your MR/PR, so I would suggest to re-trigger it when you are very sure and later you can target individual test suites individually. What I mean is that if you re-trigger for the whole architecture several times, the mess up might be tricky to delete, so please do it with granularity, the
TEST
setting might help for ISOS post.
Updated by tinawang123 over 1 year ago
- Status changed from In Progress to Resolved
Actions