action #16188


Easier way to clone jobs for test development

Added by pgeorgiadis over 7 years ago. Updated over 5 years ago.

Feature requests
Target version:
Start date:
Due date:
% Done:


Estimated time:


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 2 (1 open1 closed)

Related to openQA Project - coordination #10316: [epic] Better command line options extending "client"New2018-03-27

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

Actions #1

Updated by coolo over 6 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.

Actions #2

Updated by okurz over 6 years ago

Actions #3

Updated by okurz almost 6 years ago

  • Target version changed from future to future
Actions #4

Updated by okurz over 5 years ago

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

Updated by okurz over 5 years 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