Actions
action #156547
openQA - coordination #99303: [saga][epic] Future improvements for SUSE Maintenance QA workflows with fully automated testing, approval and release
coordination #99306: [epic] Future improvements: Make reviewing openQA results per squad easier
A single API route to show all not-ok tests blocking a SLE maintenance incident size:M
Start date:
Due date:
% Done:
0%
Estimated time:
Description
Motivation¶
From #121246-15: "We'd need to look for all the tests that are failing for a given incident, using the same TEST_ISSUES for both, Aggregates and Incidents". After #117655 we identified that we can use that to filter but there is a key/job id limit so we need to find out how to work with a much larger limit e.g. with a database index.
Acceptance criteria¶
- AC1: /job_settings/jobs can yield a sufficiently complete list of matching jobs, e.g. some weeks old
- AC2: DoS attacks using /job_settings/jobs is not feasible -> so not just remove the limit
Suggestions¶
- We can get a job for a particular incident (#117655#note-33)
- openqa-cli api --o3 /job_settings/jobs key=*_TEST_ISSUES list_value=1234567
- openqa-cli api --osd /job_settings/jobs key=LTSS_TEST_ISSUES list_value=20988
- Note there is an implicit enforced limit of 20000 jobs here (see also the later suggestion)
- Explore how to work around the key/job id limit without simply removing it, or add a way to override it or finally introduce a trigram gin index for fast text searching without limits on keys
Out of scope¶
- This doesn't need to be specific to squads/blocking tests (openQA itself should not know about these SUSE specific concepts)
Actions