Project

General

Profile

action #35595

[sle][functional][y] Inconsistency between job setting and vars.json

Added by JERiveraMoya about 2 years ago. Updated about 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Bugs in existing tests
Target version:
Start date:
2018-04-26
Due date:
% Done:

0%

Estimated time:
Difficulty:
Duration:

Description

We have found inconsistency between job setting and vars.json for s390x, for instance:
we set here DESKTOP to text mode: https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/products/sle/main.pm#L128
but we found different value of this property in https://openqa.suse.de/tests/1647514#step/php7_postgresql96/36 and https://openqa.suse.de/tests/1647514/file/vars.json.

Probably in the same way that the source code displayed is not reliable in the web ui, this settings written during scheduling aren't neither, only be able to trust in the vars.json as is written at the end.
The effect that we see with this is a wrong scheduling comparing gnome+proxy_SCC+allmodules for different architectures, for instance php7 tests are only executed in s390x.


Related issues

Related to openQA Tests - action #33985: [sle][functional][u][medium]functional tests covering php from the "web & scripting" moduleResolved2015-11-112018-08-28

History

#1 Updated by JERiveraMoya about 2 years ago

  • Related to action #33985: [sle][functional][u][medium]functional tests covering php from the "web & scripting" module added

#2 Updated by okurz about 2 years ago

  • Subject changed from [sle][functional] Inconsistency between job setting and vars.json to [sle][functional][y] Inconsistency between job setting and vars.json
  • Status changed from New to Feedback
  • Assignee set to okurz
  • Target version set to future

Well, I'm not sure what you expect should be done here.

The current way is like this: The table for "settings" are the input values, the vars.json is written at the end of the tests and test code is allowed to update the settings so I would not see it as a general issue. It certainly is an interesting design choice ;)

#3 Updated by JERiveraMoya about 2 years ago

indeed :), I guess we can reject it. I will write a comment in #33985 that is the ticket workable.

#4 Updated by okurz about 2 years ago

  • Status changed from Feedback to Resolved

ok, fine. So we have it covered in other tickets then.

#5 Updated by okurz about 2 years ago

  • Target version changed from future to future

Also available in: Atom PDF