action #111458
Updated by JERiveraMoya almost 2 years ago
#### Motivation We now have responsibility of YaST tests in [YaST Maintenance Updates](https://openqa.suse.de/group_overview/421). 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. #### Acceptance criteria **AC1**: Given an openQA job id, the script can retrieve incidents IDs filtering by product module. product. **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). #### Suggestion * Using the `openQA Job ID` we 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_ISSUES` or from the `MAINT_TEST_REPO` variables. * Script should be able to give us incident ids related to specific products, for example if we are only interested in `HPCM_TEST_ISSUES` we 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 `patchinfo` of the update. Eg for Incident ID `24365` this 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.