QA (public) » openQA Project (public)

okurz wrote:

http://open.qa/docs/#_spawning_multiple_jobs_based_on_templates_isos_post already references available scheduling parameters, e.g. there is also _ONLY_OBSOLETE_SAME_BUILD which sounds like the opposite of what you describe.

Sorry, I didn't describe clearly. Users don't want to cancel the same build. They want to cancel the older build.

What you describe with

When a new build comes, the jobs belong to group A are triggered first. Then the jobs belong to group B are triggered and with parameter _OBSOLETE=1

sounds more like a mistake done by a human operator or a bug. Can you describe the problem that happened in a bit more detail? What happens is very much dependant on what component triggers new builds. Is this based on observations from osd or another instance? What I assume should happen by default on osd is that new product builds are triggered with _DEPRIORITIZEBUILD and old builds should still have to chance to complete their tests.

I will I invite one user to answer this question.

The issue is found on our local Beijing openQA(10.67.129.4)
we have SPA-HANA and SLE-Performance job group.
1.when build 162.7 is coming,HANA trigger it's job firstly.
and performance is doing build161.1 testing.
2.Later performance trigger script found build162.7 is coming,so it's using isos post API with _OBSOLETE trigger new build.
3._OBSOLETE parameter cancel the performance build161.1 job ,

1. and also cancel the HANA build162.7 job
2. step 3 is what we want,but step 4 is not. so do you have any suggestion about how to spawning this jobs?

okurz wrote:

Xiaojing_liu wrote:

okurz wrote:

http://open.qa/docs/#_spawning_multiple_jobs_based_on_templates_isos_post already references available scheduling parameters, e.g. there is also _ONLY_OBSOLETE_SAME_BUILD which sounds like the opposite of what you describe.

Sorry, I didn't describe clearly. Users don't want to cancel the same build. They want to cancel the older build.

I know. I understood that. This is what I meant: There is already _ONLY_OBSOLETE_SAME_BUILD but what you describe sounds like the opposite is needed. So I wonder if this is a new feature that makes sense. The flag _ONLY_OBSOLETE_SAME_BUILD was introduced with https://github.com/os-autoinst/openQA/commit/16af146abceee0eb18ec11826e9803659c8f8f7c and it was not too complicated. Maybe adding a flag like _ONLY_OBSOLETE_OTHER_BUILDS would be not too hard to implement (in theory). However I currently would not plan to do that.

joyce wrote:

The issue is found on our local Beijing openQA(10.67.129.4)
we have SPA-HANA and SLE-Performance job group.
1.when build 162.7 is coming,HANA trigger it's job firstly.
and performance is doing build161.1 testing.
2.Later performance trigger script found build162.7 is coming,so it's using isos post API with _OBSOLETE trigger new build.
3._OBSOLETE parameter cancel the performance build161.1 job ,

1. and also cancel the HANA build162.7 job
2. step 3 is what we want,but step 4 is not. so do you have any suggestion about how to spawning this jobs?

Thanks for the example. I assume you trigger isos post with _OBSOLETE to cancel very long-running performance tests to run more recent tests on the same worker hardware. I think it might work to define the SAP-HANA tests as a separate product, e.g. change the medium parameters, so that the next isos post would not match the same parameters for SAP-HANA and performance tests. Please tell me if this works for you.
Thanks for your suggestion,we will try to change FLAVOR when our testing enviroment is available.