action #60371
closedFix variable precedence and predence overriding in job templates YAML documents
Added by coolgw over 4 years ago. Updated over 4 years ago.
0%
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
Updated by okurz over 4 years 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".
Updated by coolo over 4 years ago
- Category changed from Feature requests to Regressions/Crashes
- 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
Updated by Xiaojing_liu over 4 years 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:
- 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.
- 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.
Updated by coolo over 4 years 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.
Updated by Xiaojing_liu over 4 years 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.
Updated by Xiaojing_liu over 4 years ago
- Status changed from New to In Progress
Updated by Xiaojing_liu over 4 years ago
- Target version changed from Ready to Current Sprint
Updated by Xiaojing_liu over 4 years ago
- Status changed from In Progress to Feedback
Updated by Xiaojing_liu over 4 years ago
- Status changed from Feedback to Resolved
Updated by okurz over 4 years ago
checked myself again, works as expected. Great! Thank you.
Updated by AdamWill over 4 years 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.
Updated by tinita over 4 years ago
i just stumbled over this and saw that the settings can have a plus at the start, but not in the default settings.
Is this intended or should this also be allowed in the default settings?
Updated by tinita over 4 years ago
I created a PR related to that: https://github.com/os-autoinst/openQA/pull/2711
That will use the same pattern for settings in the jobs and in the defaults.
Updated by tinita over 4 years ago
- Status changed from Resolved to Feedback
- Assignee changed from Xiaojing_liu to tinita
- Priority changed from High to Low
Updated by livdywan over 4 years ago
- Blocks action #62219: jobs post does not support to trigger a test suite that is defined in YAML with a new alias added