[release-1.11] Cirrus: Add CI self-destruct condition on EOL date#1991
Conversation
This branch will never receive any security-backports when the associated RHEL release reaches EOL. Add a condition to force CI to break with a helpful message, after this RHEL EOL date. Signed-off-by: Chris Evich <cevich@redhat.com>
mtrmac
left a comment
mtrmac
left a comment
There was a problem hiding this comment.
This is assuming that the 9.3/8.9 RHELs will come from a future new branch, do I understand that correctly? Otherwise the last possible EOL seem to be further in the future.
(If that’s the intent, that’s fine; I agree it’s a good habit to have the _EOL code on all branches; we can always move the date out.)
OIC the problem. I was blindly going by a list Jindrich shared with me, cross-referencing a google sheet of RHEL releases and EOL dates, I didn't even look at the RHEL versions. Let me double-check and see if there's a release currently using 1.11 which is going EOL sooner. That's probably a safer date to use. Thanks for checking @mtrmac |
|
Err wait...the changes for this branch are for 9.2/8.2. I just double-checked, and the EOL date is correct for this branch and those RHEL releases.
Not necessarily, but those are odd-numbered releases, so they will EOL sooner. We want the EOL date set to the latest possible date (which it is). If a new branch is made for 9.3/8.9, it will need to have its own separate EOL-check added on branch creation. |
|
Actually, https://gitlab.com/redhat/centos-stream/rpms/skopeo/-/tree/c9s is now at 1.12, so a future branch will almost certainly be post-1.11, making the (already fairly hypothetical) concern of future 1.11-based branches moot. |
2 participants
This branch will never receive any security-backports when the associated RHEL release reaches EOL. Add a condition to force CI to break with a helpful message, after this RHEL EOL date.