action #30274
closedisos post sometimes trigger iso_cancel for whole product
0%
Description
this event was not directly triggered
https://openqa.suse.de/admin/auditlog?eventid=928340
most probably it is consequence of doing isos post
So, when I did following call:
client isos post ARCH=x86_64 DISTRI=sle FLAVOR=Installer-DVD VERSION=15 ISO=SLE-15-Installer-DVD-x86_64-Build418.3-Media1.iso BUILD=418.3 TEST=autoyast_multipath --host https://openqa.suse.de
In the audit logs of openQA I got an entry with my name:
7 minutes ago riafarov iso_cancel { "VERSION": "15", "FLAVOR": "Installer-DVD", "ARCH": "x86_64", "DISTRI": "sle" }
Even though I haven't called cancel explicitly. So, it looks like client wanted to obsolete the run, but instead of single test suite, it has canceled all of them for defined medium.
As a workaround one can use _NOOBSOLETEBUILD=1 option not to obsolete jobs, which should help.
Updated by coolo over 6 years ago
- Subject changed from [tools] isos post sometimes trigger iso_cancel for whole product to isos post sometimes trigger iso_cancel for whole product
- Category set to Feature requests
- Priority changed from Urgent to Normal
- Target version set to Ready
This is not urgent as there is a workaround. And this has been the case forever - when TEST= support was implemented, it was never considered to be a shot afterwards
Updated by okurz over 6 years ago
- Related to coordination #10316: [epic] Better command line options extending "client" added
Updated by okurz over 6 years ago
I think everything works as designed so even calling the use of the no-obsolete variable a "workaround" is maybe not appropriate.
Albeit I think that the default behaviour of "isos post" could be made more "safe" as in do not cancel any existing tests by default. So basically turn the default around and make "OBSOLETION" an optional feature that can be requested with an according parameter.
Updated by mkittler over 5 years ago
So not a bug after all and just a bad default? Changing the default would be a breaking API change (even though in the direction of "being safer").
Updated by okurz over 5 years ago
yes to all, still, if you could provide a PR to do this I guess we can go forward
Updated by Xiaojing_liu almost 5 years ago
- Status changed from New to In Progress
- Assignee set to Xiaojing_liu
Updated by Xiaojing_liu over 4 years ago
Updated by coolo over 4 years ago
- Target version changed from Ready to Current Sprint
Updated by Xiaojing_liu over 4 years ago
- Status changed from In Progress to Feedback
Updated by Xiaojing_liu over 4 years ago
- Status changed from Feedback to Resolved