[release-5.27] Test the release-5.27 branch against the 1.13 branch of Skopeo

[mtrmac]

Skopeo has updated golang.org/x/exp to an API-incompatible version, so test this stable branch against a corresponding Skopeo stable branch.

[mtrmac]

@cevich Per the email thread, I’d like to use a release-5.27 branch and a 5.27.0 release, instead of the upcoming 5.26 branch.

Would it be possible to set up Cirrus to run tests on the 5.27 branch (and possibly drop the 5.26 one, please? It seems I don’t have the permissions to see those Cirrus settings (and that’s probably correct).

Or, if this is unreasonable, please say so and we’ll stay on 5.26 with a pedantically-incorrect version name.

[mtrmac]

In the meantime #2075 is, among other things, testing that this change actually works.

[flouthoc]

LGTM

[flouthoc]

@mtrmac Tests seems to be running now ? Is this okay to merge ?

[mtrmac]

Oops, so I was just impatient? Or did Chris make that happen?

Either way, merging.

[cevich]

Would it be possible to set up Cirrus to run tests on the 5.27 branch (and possibly drop the 5.26 one, please? It seems I don’t have the permissions to see those Cirrus settings (and that’s probably correct).

Yep, this is really easy to do. I checked the settings, you should have access now (and should have had them before as well, dunno, github permissions are ugly/broken/non-intuitive).

[cevich]

Oh...One more thing: Do you want us to receive e-mail alerts if/when the job fails?

Note: The only cirrus-ci job I see on this repo. is a nightly job on `main.

[mtrmac]

@cevich Thanks.

We are using 5.26 after all, so I have replaced the release-5.27 schedule with a release-5.26 one again.

---

Oh...One more thing: Do you want us to receive e-mail alerts if/when the job fails?

Note: The only cirrus-ci job I see on this repo. is a nightly job on main.

I’m afraid that’s my mistake — I thought that there are already periodic jobs in this repo, and I just wanted to redirect the 5.26 activity to 5.27 (which is no longer the plan, as of today). I didn’t intend to initiate regular testing of code that we previously didn’t want to test.

I have little opinion on whether we should have periodic jobs on c/image (on main, or on the release branches) in the first place. There’s some value in knowing that we can immediately build the stable branches, OTOH I don’t know what it costs.

We do have several periodic jobs running for Skopeo; that’s not exactly the same (in case of commits on c/image not yet vendored into Skopeo) but it’s almost the same, and quite possibly sufficient.

WRT email alerts, is anyone watching and anyone notice a failing job without a notification? The usual Podman-monitor destination seems useful — but that’s all only assuming we need to run the job.

[cevich]

WRT email alerts, is anyone watching and anyone notice a failing job without a notification? The usual Podman-monitor destination seems useful — but that’s all only assuming we need to run the job.

Nobody will notice if the jobs fail. I opened #2082 which will automatically retry failed jobs (once) and send notifications. The only thing missing in the setup is me copy/pasting over the required e-mail notice secrets.