Create a small cli/script to help debugging failures with maintenance updates
We now have responsibility of YaST tests in YaST Maintenance Updates.
This means that we will have to debug failures that could be caused by maintenance updates installed on the systems of those runs.
In order to facilitate with this it would be convenient to have a tool that shows a small overview of the maintenance updates that are applied to a job.
AC1: Given an openQA job id, the script can retrieve incidents IDs filtering by product module.
AC2: The script can query information for those IDs that helps to debugs problems (for instance patchinfo)
AC3: The script should be simple enough, containing a few lines that are easy to maintain.
AC4: Consider how we could filter YaST related updates with the final output (not implementation required).
openQA Job IDwe should be able to construct the var.json url of the job (eg
https://openqa.suse.de/tests/8805896/file/vars.json). We can either parse the .json file to get get the Incident IDs from
.*_TEST_ISSUESor from the
Script should be able to give us incident ids related to specific products, for example if we are only interested in
HPCM_TEST_ISSUESwe could filter by HPCM, but also we could also interested on ASMM, so we could specify a comma-separated list
HPCM,ASMM. Without filter we should get all of them present in the vars.json.
For each Incident ID we should be able to get the
patchinfoof the update. Eg for Incident ID
24365this can be done either via getting the file https://build.suse.de/source/SUSE:Maintenance:24364/patchinfo/_patchinfo , or by scraping https://build.suse.de/package/view_file/SUSE:Maintenance:24365/patchinfo/_patchinfo?expand=1 , or via osc commands. All three methods require a login first.
The tool should output a small amount of information for each Incident ID. The patchinfo file may contain more info than needed so it could need additional parsing.
Once we have a script easy to maintain for us if we would see that we need more features, we will be in a better position to know what we want exactly and we can consider other existing and more powerful tools in that case, but likely this would be enough for our goal.
Perhaps just grep by "yast" is enough but perhaps there are more YaST components or maintained by YaST developers which do not start by "yast". We could figure out or ask them, but we don't need to implement that additional filtering for now.
Updated by geor almost 2 years ago
I am a bit confused as to what AC1 means now.
On another note, concerning suggested implementations, I believe the best approach would be to construct the vars.json url with the required openQA job ID, pipe it to
jq to get the Incident IDs, and use
osc to get the patchinfo for each of those Incidents. Using osc (
zypper in osc) is a good approach to the logging in part, since the user can define their .oscrc config with build.suse.de credentials.