action #16188

Easier way to clone jobs for test development

Added by pgeorgiadis about 3 years ago. Updated about 1 year ago.

Status:ResolvedStart date:23/01/2017
Priority:NormalDue date:
Assignee:okurz% Done:


Category:Feature requests
Target version:QA - future


In order to contribute to openQA, most of the people I know of, they are cloning a job from [] and then they add their test into that. So, while they are writing their new test, they have to run the whole build which might be consisted of 20-30 tests more or less. So, instead of waiting for a number of unreleated tests to finish (waste of time), I would like to propose a functionality where you can run only one = the test you are developing and you are interested into (e.g. java, or unzip).

So far, I managed to do that (credits to @Romanos) by creating a new medium, a new testsuite, a new jobgroup and modifying the accordingly. As a side effect, I have to play with git stash save and git stash pop and be careful to not submit unwanted changes (this hack) in The whole workflow is documented [here] and [here], but instead of working around it, I would prefer an official solution to that problem. Probably you guys have already something in mind ;)

Related issues

Related to openQA Project - action #10316: [epic] Better command line options extending "client" In Progress 27/03/2018
Related to openQA Tests - action #44420: [functional][y][timeboxed:6h] proof-of-concept of declara... Resolved 28/11/2018 26/02/2019


#1 Updated by coolo over 2 years ago

  • Subject changed from Isolated test runs to Easier way to clone jobs for test development
  • Target version set to future

unfortunately not. What we can do is cloning the job with a setting where to insert your test so that the first run creates a qcow with the snapshot before that point. So that successive runs can start from that snapshot. But you can't isolate a test from the rest generically - as the SUT needs to be prepared in a custom way.

#2 Updated by okurz about 2 years ago

  • Related to action #10316: [epic] Better command line options extending "client" added

#3 Updated by okurz over 1 year ago

  • Target version changed from future to future

#4 Updated by okurz about 1 year ago

  • Related to action #44420: [functional][y][timeboxed:6h] proof-of-concept of declarative test schedule definition, e.g. in YAML file(s) added

#5 Updated by okurz about 1 year ago

  • Status changed from New to Resolved
  • Assignee set to okurz

With and we have two new variables for controlling the schedule so three in total: INCLUDE_MODULES, EXCLUDE_MODULES as well as SCHEDULE to define a completely custom schedule. In many cases people already use this to schedule a minimum test schedule, e.g. openqa-clone-job … <id> SCHEDULE=tests/boot/boot_to_desktop,tests/my/module . I guess this is (nearly) as simple as it gets. We could only work towards having tests/my/module depend automatically on tests/boot/boot_to_desktop but I guess this is out of scope for this ticket but could be covered by #44420

Also available in: Atom PDF