action #25412

Clone_job: support global variables

Added by zluo over 2 years ago. Updated over 1 year ago.

Status:ResolvedStart date:19/09/2017
Priority:NormalDue date:
Assignee:mitiao% Done:

0%

Category:Feature requests
Target version:Done
Difficulty:
Duration:

Description

Doing clone_job.pl --skip-chained-deps --skip-download --from http://openqa.suse.de 1173559 WORKER_CLASS=local

Creates

Created job #4099: sle-15-Leanos-DVD-x86_64-Build260.4-autoyast-supportserver@64bit -> http://localhost/t4099
Created job #4100: sle-15-Leanos-DVD-x86_64-Build260.4-sles12_autoyast_tftp@64bit -> http://localhost/t4100

While sle-15-Leanos-DVD-x86_64-Build260.4-sles12_autoyast_tftp@64bit ended up with WORKER_CLASS=local it's parent job sle-15-Leanos-DVD-x86_64-Build260.4-autoyast-supportserver@64bit did not (It kept the values from the original job).

History

#1 Updated by coolo almost 2 years ago

  • Subject changed from Clone job does not copy settings to chained jobs to Clone_job: support global variables
  • Category changed from Concrete Bugs to Feature requests
  • Target version set to Ready

This is a feature - as the variables you give there are for the jobs to be cloned. WORKER_CLASS (and possibly other machine related variables) need to be differed. But perhaps you realize the problem if you consider that I use TEST very often for clone_job to give the clone a different name. Having this in the parents too doesn't make sense.
But even things like QEMUCPU are not necessarly also for the dependencies (imagine you're cloning parallel jobs, not chained ones).

So IMO what we need is a switch in clone_job for variables to be passed to dependent jobs.

#2 Updated by oorlov over 1 year ago

Today I've also noticed that behavior while cloning child job with the custom WORKER_CLASS parameter. The parent did not get the same worker class name and did not start. Would be a nice feature to pass the WORKER_CLASS parameter to parent job.

#3 Updated by mitiao over 1 year ago

  • Assignee set to mitiao
  • Target version changed from Ready to Current Sprint

#4 Updated by mitiao over 1 year ago

so what other global variables like WORKER_CLASS we are using?

#5 Updated by mitiao over 1 year ago

  • Status changed from New to In Progress

#6 Updated by mitiao over 1 year ago

  • Status changed from In Progress to Resolved

pr merged with minor refactor and unit test added.

#7 Updated by szarate over 1 year ago

  • Target version changed from Current Sprint to Done

Also available in: Atom PDF