Project

General

Profile

Actions

action #60371

closed

Fix variable precedence and predence overriding in job templates YAML documents

Added by coolgw about 4 years ago. Updated about 4 years ago.

Status:
Resolved
Priority:
Low
Assignee:
Category:
Regressions/Crashes
Target version:
Start date:
2019-11-28
Due date:
% Done:

0%

Estimated time:

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

Related issues 1 (0 open1 closed)

Blocks openQA Project - action #62219: jobs post does not support to trigger a test suite that is defined in YAML with a new aliasClosedXiaojing_liu2020-01-17

Actions
Actions #1

Updated by okurz about 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".

Actions #2

Updated by coolo about 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

Actions #3

Updated by Xiaojing_liu about 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:

  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.

Actions #4

Updated by coolo about 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.

Actions #5

Updated by Xiaojing_liu about 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.

Actions #6

Updated by Xiaojing_liu about 4 years ago

  • Assignee set to Xiaojing_liu
Actions #7

Updated by Xiaojing_liu about 4 years ago

  • Status changed from New to In Progress
Actions #8

Updated by Xiaojing_liu about 4 years ago

  • Target version changed from Ready to Current Sprint
Actions #9

Updated by Xiaojing_liu about 4 years ago

  • Status changed from In Progress to Feedback
Actions #10

Updated by Xiaojing_liu about 4 years ago

  • Status changed from Feedback to Resolved
Actions #11

Updated by okurz about 4 years ago

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

Actions #12

Updated by AdamWill about 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.

Actions #13

Updated by tinita about 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?

Actions #14

Updated by tinita about 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.

Actions #15

Updated by tinita about 4 years ago

  • Status changed from Resolved to Feedback
  • Assignee changed from Xiaojing_liu to tinita
  • Priority changed from High to Low
Actions #16

Updated by livdywan about 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
Actions #17

Updated by livdywan about 4 years ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF