Project

General

Profile

Actions

action #6762

closed

make BUILD mandatory variable?

Added by lnussel about 9 years ago. Updated almost 7 years ago.

Status:
Resolved
Priority:
Low
Assignee:
Category:
Feature requests
Target version:
-
Start date:
2015-03-18
Due date:
% Done:

0%

Estimated time:

Description

Since BUILD is used for links in the tests overview page we should consider making it mandatory just like DISTRI, VERSION, FLAVOR, ARCH

Actions #1

Updated by okurz over 8 years ago

  • Category set to Feature requests
Actions #2

Updated by okurz over 7 years ago

There has been an discussion in https://github.com/os-autoinst/openQA/pull/1119#pullrequestreview-14901136 about that and other variables, too. I suggest to not make any of these variables mandatory because they are just not necessary this is also why there is no big problem so far about it when jobs do not set it, there will just be a perl warning in the log file.

Actions #3

Updated by oholecek over 7 years ago

What is the purpose of job without DISTRI? I don't mind making the other optional.

Actions #4

Updated by okurz over 7 years ago

oholecek wrote:

What is the purpose of job without DISTRI?

Why not having a job with no distri? What do we need it for? I know what we use it for, but IMHO we do not need it in all cases.

Actions #5

Updated by oholecek over 7 years ago

Both CASEDIR and PRODUCTDIR use DISTRI to construct where the tests actually are. How will isotovideo know what tests to run without DISTRI? Or do we have some new tricks around this?

Actions #6

Updated by okurz over 7 years ago

well, you showed how, using CASEDIR and PRODUCTDIR :-)

Actions #7

Updated by okurz over 7 years ago

  • Status changed from New to In Progress
  • Assignee set to okurz
Actions #8

Updated by oholecek over 7 years ago

well, you showed how, using CASEDIR and PRODUCTDIR :-)

Yes, but then there must be check if DISTRI or CASEDIR or PRODUCTDIR is set for a job. We don't have it and all the code I looked in assumed DISTRI is there => new uninitialized vars warnings.

Actions #9

Updated by okurz over 7 years ago

  • Target version set to Milestone 5
Actions #10

Updated by okurz about 7 years ago

  • Target version changed from Milestone 5 to Milestone 6
Actions #11

Updated by okurz about 7 years ago

  • Priority changed from Normal to Low
  • Target version changed from Milestone 6 to Milestone 7

It's not important, right? I keep coming back to this from time to time but not investing a lot. Proper way as discussed in https://github.com/os-autoinst/openQA/pull/1126#issuecomment-270143989 would be "make these values required in the schema with default to empty strings; database migration scripts to find all current undef values in the database and update to empty string"

Actions #12

Updated by okurz about 7 years ago

  • Status changed from In Progress to Feedback

waiting for feedback on PR

Actions #13

Updated by okurz almost 7 years ago

  • Target version deleted (Milestone 7)

got feedback. Have database migration scripts, tests pass but it seems like I can still produce local perl warnings. I want to revisit if I can extend the tests to cover this. As this ticket is low I don't see a general problem to carry it over but now as I moved it around long enough I guess I will just delete the milestone assignment.

Actions #14

Updated by okurz almost 7 years ago

PR merged - sometimes things go faster than expected ;-) Not yet deployed on o3 or osd, waiting ...

Actions #15

Updated by okurz almost 7 years ago

  • Status changed from Feedback to Resolved

deployed on osd, no warnings seen in logs regarding that for now.

Actions

Also available in: Atom PDF