action #111458

Create a small cli/script to help debugging failures with maintenance updates

Added by geor about 1 month ago. Updated about 1 month ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:



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.

Acceptance criteria

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).


  • Using the openQA Job ID we should be able to construct the var.json url of the job (eg 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 , or by scraping , 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.


#1 Updated by geor about 1 month ago

  • Description updated (diff)

#2 Updated by okurz about 1 month ago could be a good start for a CLI. Alternatives are openqa-cli or or just the plain openQA API directly.

#3 Updated by JERiveraMoya about 1 month ago

  • Subject changed from Create a cli tool that outputs a small summary of an openQA job's maintenance updates to Create a small cli/script to help debugging failures with maintenance updates
  • Description updated (diff)

#4 Updated by geor about 1 month 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 credentials.

#5 Updated by JERiveraMoya about 1 month ago

  • Description updated (diff)

#6 Updated by JERiveraMoya about 1 month ago

Fixed AC1 to reflect that is not needed for now to use api secret to query openqa when we can construct the url for now.

#7 Updated by JERiveraMoya about 1 month ago

  • Tags deleted (qe-yast-refinement)
  • Description updated (diff)
  • Status changed from New to Workable

Also available in: Atom PDF