Project

General

Profile

Actions

action #21848

open

error when using multiple parent jobs in START_AFTER_TEST parameters

Added by riafarov over 7 years ago. Updated over 4 years ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
Feature requests
Target version:
QA (public, currently private due to #173521) - future
Start date:
2017-08-09
Due date:
% Done:

0%

Estimated time:

Description

START_AFTER_TEST allows multiple values separated by comma.
Our need was to have 2 different parent test suites in different job groups and child jobs in same and other job groups.
We trigger jobs for specific scenario and with defined flavor, so it's never the case that we simultaneously trigger two parent jobs with one post isos call.

So we have following scenario:
Job group A contains test suite parent_A and medium SLE12-SP3
Job group B contains test suite parent_B and medium SLE15
Job group C contain child test suite child_AB with medium SLE12-SP3
Job group C contain child test suite child_AB with medium SLE15
child_AB has setting START_AFTER_TEST=parent_A,parent_B
When we do isos post with FLAVOR=SLE12-SP3 we get an error:
error_messages => [
"START_AFTER_TEST=parent_A:64bit not found - check for typos and dependency cycles",
],

When we do isos post with FLAVOR=SLE15 we get an error:
error_messages => [
"START_AFTER_TEST=parent_B:64bit not found - check for typos and dependency cycles",
],

Frankly speaking this is relevant error for some cases and also is the reason why this flow works for us and allows us to have multiple parent test suites and reuse same child test suites for all of them.

Actions #1

Updated by coolo over 6 years ago

  • Subject changed from [tools] error when using multiple parent jobs in START_AFTER_TEST parameters to error when using multiple parent jobs in START_AFTER_TEST parameters

So if I get you right, you want the error to be silent? Because to me this sounds like an abuse. But a proper solution would mean having conditionals expressed in STARTS_AFTER and I'm not so sure we want to go there.

Actions #2

Updated by okurz over 6 years ago

Yes, I would be also ok with turning the error to info and describing the behaviour as feature. If you agree with that then I think this ticket could be a perfect "easy hack" for new contributors :)

Actions #3

Updated by coolo over 6 years ago

Well, we still need feedback on typos. It's just a string after all - and the error is already just a warning. It doesn't hinder anything. So I'm inclined to change anything

Actions #4

Updated by coolo over 6 years ago

I guess I used inclined wrong :)

Actions #5

Updated by riafarov over 6 years ago

As @okurz mentioned it's a hidden feature which serves our needs, changing error message to info would mean that chances to make it work differently is lower. I believe we can improve job dependencies handling for more complex scenarios. So error message is just misleading when we abuse this behavior, for me main point is not to change scheduler behavior (e.g. cancel if there are errors).

Actions #6

Updated by okurz over 5 years ago

  • Category set to Feature requests
Actions #7

Updated by okurz over 4 years ago

  • Priority changed from Normal to Low
  • Target version set to future
Actions

Also available in: Atom PDF