action #175392
closed
[BCI] Integrate IBM HPVS into the container-release-bot
Added by ph03nix about 1 month ago.
Updated 19 days ago.
Description
#163190 implemented test runs running on the IBM Hyper Protect Virtual Servers. Those jobs are triggered via a Gitlab CI and are not yet integrated into the container-release-bot pipeline.
For IBM HPVS testing we schedule the test runs after those images are released because we cannot access registry.suse.de.
See https://gitlab.suse.de/qac/container-release-bot/-/issues/20 - this is about adding post-release triggers to the container-release-bot
Acceptance criteria¶
- AC1 : The crb allows configuration of post-release triggers, i.e. triggering custom openQA test runs AFTER a container is released
- AC2 : For the busybox BCI containers, we schedule openQA test runs for the IBM HPVS after those containers are released
Note that post-release triggers should only schedule openQA test runs. They do not need to observe them, or wait for them to pass. The aim is only scheduling.
Further References¶
- Related to action #168286: [containers] Evaluate status of IBM cloud testing added
- Related to action #163190: [IBM-HPVS] Establish workflow to run custom BCI container commands and obtain the logs added
- Description updated (diff)
- Tags changed from bci, difficult to bci, difficult, to-be-refined
- Status changed from Workable to Blocked
- Tags changed from bci, difficult, to-be-refined to bci
- Description updated (diff)
- Status changed from Blocked to Workable
- Status changed from Workable to In Progress
- Assignee set to rmarliere
- Status changed from In Progress to Resolved
The MR was closed after some more consideration. @ph03nix made the remark that container-release-bot should stay as simple as possible and since this new logic would inevitably have to add some sort of additional state within the openQA jobs (e.g. through a flag string appended to the "build" as suggested in the MR) and also deal with the problem of time delays regarding image building and releasing (which is not ideal in such stateless tool which can be ran at any given point in time), it's simply not worth the trouble. It was decided that additional tools such as the blue-moon-launcher project should be used, instead.
rmarliere wrote in #note-8:
The MR was closed after some more consideration. @ph03nix made the remark that container-release-bot should stay as simple as possible and since this new logic would inevitably have to add some sort of additional state within the openQA jobs (e.g. through a flag string appended to the "build" as suggested in the MR) and also deal with the problem of time delays regarding image building and releasing (which is not ideal in such stateless tool which can be ran at any given point in time), it's simply not worth the trouble. It was decided that additional tools such as the blue-moon-launcher project should be used, instead.
Ack.
Also available in: Atom
PDF