action #60371

Fix variable precedence and predence overriding in job templates YAML documents

Added by coolgw about 1 month ago. Updated 15 days ago.

Status:ResolvedStart date:28/11/2019
Priority:HighDue date:
Assignee:Xiaojing_liu% Done:

0%

Category:Concrete Bugs
Target version:Current Sprint
Difficulty:
Duration:

Description

Motivation

Base on the http://open.qa/docs/#_variable_precedence it is possible to use a plus prefix in front of a variable name to override precedence which is currently not support in job template YAML documents nor does the job template seem to have higher precedence

Suggestions

  • Make sure the variables in job templates have highest predence
  • Allow to prefix values with + in YAML job templates
  • Ensure predence overriding works in YAML job templates

History

#1 Updated by okurz about 1 month ago

  • Subject changed from support _variable_precedence in yaml file to Fix variable precedence and predence overriding in job templates YAML documents
  • Description updated (diff)
  • Category set to Feature requests

I checked myself and it is correct that neither does the job template seem to have higher precedence – which IMHO it should – nor is it allowed to prefix a "+" to override. What I tested: On http://lord.arch I added a setting "TEST=foo" to the testsuite "foo" on http://lord.arch/admin/test_suites , added a setting "FOO: bar" in job templates http://lord.arch/admin/job_templates/1 and scheduled openqa-client --host http://lord.arch isos post ARCH=x86_64 DISTRI=opensuse FLAVOR=DVD VERSION=1. Checked for the generated job and the expected setting with openqa-client --json-output --host http://lord.arch jobs latest=1 version=1 state=scheduled distri=opensuse | jq -r '.jobs | .[] | .settings | .TEST' | (! grep -v bar) which failed as there is still "foo".

#2 Updated by coolo about 1 month ago

  • Category changed from Feature requests to Concrete Bugs
  • Priority changed from Normal to High
  • Target version set to Ready

Variables set in yaml need to have top priority - and then we don't need any overwrites. I see this as a bug - everywhere (including you) expect it this way

#3 Updated by Xiaojing_liu about 1 month ago

coolo wrote:

Variables set in yaml need to have top priority - and then we don't need any overwrites. I see this as a bug - everywhere (including you) expect it this way

The user story's step is:
1. When openqa trigger jobs automatically (for example there is a new build), the ISO will be set. (I did not check the code, just think it according to the result, maybe I am wrong.) But for migration team, the ISO value is wrong, they want to set this value by themselves.
2. So they try to define the ISO in YAML using +ISO. As openqa's document, a setting start with + has the top priority. But our YAML does not support the settings property start with +.

I also confirmed, we just need to modify the regex ^[A-Z_]+[A-Z0-9_]*$ that defined in JobTemplates-01.yaml to ^[A-Z_+]+[A-Z0-9_]*$, it will make sense to their requirements.

And IMHO, why the variables set in YAML need to have top priority? From a QA's view, we also need to modify the setting when trigger a job using client isos post and clone_job to confirm something. If the variables set in YAML have a top priority, we need to modify the YAML file every time when we want to confirm some variables. It's not convenient.

#4 Updated by coolo about 1 month ago

Fair point. So the api variables overrule. But the settings in the job group yaml need to take preference over machine,testsuite and product. So the value in allowing +ISO there is to overrule even variables from command line.

#5 Updated by Xiaojing_liu about 1 month ago

coolo wrote:

Fair point. So the api variables overrule. But the settings in the job group yaml need to take preference over machine,testsuite and product. So the value in allowing +ISO there is to overrule even variables from command line.

Yes. In my test, the settings in the job group yaml have already taken preference over machine, testsuite and product.

#6 Updated by Xiaojing_liu about 1 month ago

  • Assignee set to Xiaojing_liu

#7 Updated by Xiaojing_liu about 1 month ago

  • Status changed from New to In Progress

#8 Updated by Xiaojing_liu about 1 month ago

  • Target version changed from Ready to Current Sprint

#9 Updated by Xiaojing_liu about 1 month ago

  • Status changed from In Progress to Feedback

#10 Updated by Xiaojing_liu about 1 month ago

  • Status changed from Feedback to Resolved

#11 Updated by okurz about 1 month ago

checked myself again, works as expected. Great! Thank you.

#12 Updated by AdamWill 15 days ago

Just for future notice, this is very important functionality for Fedora, we use it quite a bit, specifically the bit about having a value set in the templates override a value passed in by the scheduler in certain cases. So thanks for fixing it.

Also available in: Atom PDF