action #30730
Updated by mgriessmeier over 6 years ago
**== User story ==** Right now I'm facing the issue that I want to retrigger a subset of jobs from one medium. All of them are booting a HDD Image so they all have the variable START_AFTER_TEST=create_hdd_textmode set. Since it is a retrigger of those because I had to change some variables in the webui, I don't want to trigger the parent creation job triggered again, since it already passed and the qcow image is present - but this is exactly what happens This could be improved (e.g. checking if the qcow is already present) to reduce test-execution time and reducing chance of possible failures for other tests relying on that qcow image (e.g. when it gets newly published during another test runs) **== Steps to "reproduce" ==** I have 3 jobs given, `hpc_conman`, `hpc_powerman` and `hpc_hwloc` which are in a job group called HPC and should be triggered for x86_64 and aarch64. all three have in common - START_AFTER_TEST=create_hdd_textmode - BOOT_HDD_IMAGE=1 - HDD_1=sle-%VERSION%-%ARCH%-%BUILD%-textmode@%MACHINE.qcow2 I change some settings in the webui to those jobs and execute following command from my local machine with the intention to trigger those three jobs for aarch64 ''' usr/bin/openqa-client isos post --host openqa.suse.de DISTRI=sle VERSION=15 FLAVOR=Installer-DVD ARCH=aarch64 ISO=SLE-15-Installer-DVD-aarch64-Build422.1-Media1.iso BUILD=422.1 DESKTOP=textmode TEST=hpc_hwloc,hpc_conman,hpc_powerman ''' what I get is ''' { count => 4, failed => [], ids => [1410023 .. 1410026] } ''' crosschecking with openQA shows me that my three jobs were triggered along with "create_hdd_textmode@aarch64" - even though the HDD_1 which should be used was already present on o.s.d I've did that several times today, because HPC jobgroup is more like a development job group right now (I know... we should have a dedicated group for that, but PO doesn't want to) => https://openqa.suse.de/tests/1410023#previous shows 5 runs for Build 422.1 I've tried two things to do the trick, but failed. - adding START_AFTER_TEST=0 to the isos post call leads to ´START_AFTER_TEST=0:aarch64 not found - check for typos and dependency cycles` - leaving it just blank with "START_AFTER_TEST=" was triggering the creation job as well **== Acceptance Criteria ==** so in order to have this working I would consider following acceptance criterias - isos post can be used like it is now, with all the variables from the job and - either checks if the HDD_1 it should use does already exist and doesn't need to be created - or checks the state of the last execution of the parent job and only triggers it if that latest run failed