QA » openQA Project

Motivation¶

Related to a discussion with fniederwanger who brought up the idea of "tagging" jobs retroactively so like job settings but something that can be added after jobs are finished. We have job settings which can come from various sources. Job settings are already used to add metadata like comments on jobs, often with a special syntax like _COMMENT=…. Additionally we can add comments on jobs as well as job groups but comments are independant of job settings. To provide clean and easily discoverable and searchable entities to denote metadata on openQA jobs we can combine both concepts.

Ideas¶

• In job groups we already have a concept of "build tagging" so we could just extend that and allow to "tag" jobs as well. For this we could use the openQA job comment field, extend the help on the editor view and add "tagging"
• Tags on job comments could show up in the job settings tag which we might want to rename to "settings & tags"
• Any job setting defined at any location, e.g. job templates, test suites, machine, worker, comment, could be specified in special format like "tag:team:awesome" which would then create a tag with key "team" and value "awesome" on any resulting openQA job both when the tag exists from the beginning when jobs are created as well as retroactively, e.g. over a dedicated API or job comment added by human operators or bots
• For internal implementation okurz suggests to just use job settings so no need for a complicated separate entity and separate database table(s) etc.
  • Just use special handling of job settings with a special name (example: key="tag:team" means a setting is a tag. Alternative: Anything starting with a special reserved character, e.g. ":" or "_")
  • Potentially extend the table(s) with a flag denoting the type of a setting if it's a tag or not
• Tags should be searchable just like job settings and comments are
• If it helps nomenclature we could call "tags" a specialized subset of settings
• Consider complete CRUD of tags, e.g. also how to delete tags
• Consider overwriting and overriding of tags. Possibly we can just rely on how job settings are treated including possibility to overwrite variables by precedence based on where settings are defined as well as overriding with the special "+" syntax