Cirrus: Use branch-specific container image tag

[cevich]

N/B: This is against the v1.4.2-stable branch, not master.

Signed-off-by: Chris Evich [email protected]

[mheon]

Uh-oh. Are we using the same test images for this branch as master? We can't drop OSTree in a stable stream, so we might need to re-add it to all the images until we no longer support a release with it.

[mheon]

/approve

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cevich, mheon

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [mheon]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[cevich]

Uh-oh. Are we using the same test images for this branch as master?

Yes, this is exactly the problem. So before we can fix it here (by adding branch-specific builds to quay) we need this (otherwise CI on master will break):

#4503

[mheon]

With #4503 landed I think this needs a rebase

[github-actions]

This pull request had no activity for 30 days. In the absence of activity or the "do-not-close" label, the pull request will be automatically closed within 7 days.

[rhatdan]

@cevich You still working on this one?

[cevich]

I think so, maybe. I'll peek at it next year 😄

[cevich]

Update: Since the container-based tasks weren't running, meta never touched the VM images, causing them to be considered disused and pruned. This is bad, but hopefully not irrecoverable. Attempting to rebuild the VM images, then I'll manually mark them to be preserved.

[cevich]

@mheon this PR seems to be failing on a bunch of podman & test issues I'm pretty sure we've fixed in master. Does that mean there is back-porting work to be done here and for RHEL?

[mheon]

Hm. Our ability to do that for non-critical bugs is somewhat limited. I don't know how much we can justify changing (and how much we actually want to - patching 1.0.x has become actively painful at this point)

[cevich]

for non-critical bugs is somewhat limited

Yep I understand on all accounts.

What about only updating ./test/ maybe? I can attempt that, just not sure if/how it will work. The other-side of the coin is needing to test some critical update, but have automation break 😖

[cevich]

Another idea: I can simply make all the CI tasks "optional" on this branch. They'll still run and report, just won't block anything.

[cevich]

@mheon okay, well it's kind of gray-green status now 😄 Good 'nuff?

[mheon]

Certainly better than how things were... We can work the rest later if we end up with further backport requests.

[cevich]

Okay, this is ready to go then.

[rhatdan]

This LGTM
But should we update the images now, they are looking a little old.

[cevich]

@rhatdan that's intentional: This is the v1.4.2-stable branch, so it SHOULD be running whatever was "current" at time of branching. Unless I'm misunderstanding something.

[mheon]

/lgtm