[release-5.19 backport] Cirrus: Update to F36 VMs

[lsm5]

Signed-off-by: Chris Evich cevich@redhat.com
(cherry picked from commit 90eec84)
Signed-off-by: Lokesh Mandvekar lsm5@fedoraproject.org

[lsm5]

CGO_CFLAGS="" CGO_LDFLAGS="-L/usr/lib64 -lgpgme" GO111MODULE=on go build -mod=vendor "-buildmode=pie" -ldflags '-X main.gitCommit=1fe8da63a9ed49de41e8c185e6c9970fafdb13dc ' -gcflags "" -tags "btrfs_noversion libdm_no_deferred_remove" -o bin/skopeo ./cmd/skopeo
# github.com/containers/skopeo/cmd/skopeo
cmd/skopeo/copy.go:249:4: unknown field 'SignIdentity' in struct literal of type copy.Options
make: *** [Makefile:140: bin/skopeo] Error 2

Exit status: 2

does this need a change in the skopeo version used in cirrus?

[mtrmac]

Yes — update SKOPEO_BRANCH.

[mtrmac]

Uh, that was apparently left over — I guess we were saved by a redirect.

But in this case the 5.19 version of c/image needs to be testing with a 5.19-using version of Skopeo, something like v1.6.2.

[lsm5]

hmm, so IIUC, that would be handled in SKOPEO_CIDEV_CONTAINER_FQIN: "quay.io/libpod/skopeo_cidev:${IMAGE_SUFFIX}" ?? I see that the IMAGE_SUFFIX is a quay.io repo tag and I don't think there's an easy mapping of repo tag <-> skopeo version, or am I looking in the wrong place?

/cc @cevich

[mtrmac]

Oops, my mistake, SKOPEO_REPO and SKOPEO_BRANCH seems to be completely unused now.

The right variable is SKOPEO_CI_TAG in .cirrus.yml; that’s consumed in contrib/cirrus/runner.sh to check out the relevant Skopeo version.

[mtrmac]

Those unused variables will be fixed on the main branch by #1541.

[cevich]

Ya, I think you're on the right track. There is no hard correlation between branch, tag, and $IMAGE_SUFFIX. So long as the $IMAGE_SUFFIX is consistent between VMs and container images, as was tested when the $IMAGE_SUFFIX. The tricky thing for release branches is, we cannot easily go back and build new "old" images (for example if they were to get pruned due to disuse). Hopefully that makes sense.

[mtrmac]

sed: can't read /etc/containers/storage.conf: No such file or directory

… So Skopeo will need (some parts of) containers/skopeo#1631 , backported to the relevant branch.

The perils of being the first change on an older branch that is not being regularly tested…

[mtrmac]

@lsm5 containers/skopeo#1637 should help with the storage.conf failure; then this PR should change again, to target Skopeo’s (unreleased) release-1.6 branch, rather than the specific v1.6.2 tag.

[cevich]

The perils of being the first change on an older branch that is not being regularly tested…

Yep, you said it correctly 😞 I'm seriously thinking this may need to change. In recent memory, I think this is the third or fourth time there's been a problem(?). While I can't do anything about old images that were already pruned. If there are release branches we should preserve going-forward (i.e. with "not yet dead" VM images), we can do something about that. Just send me the branch names and/or add them into the cirrus-cron schedule yourself (config page), the docs are short and helpful too.

[mtrmac]

While I can't do anything about old images that were already pruned. If there are release branches we should preserve going-forward (i.e. with "not yet dead" VM images), we can do something about that.

If you asked me yesterday, I wouldn’t have, from memory, pointed at this one as necessary…

Ideally I’d dream of RHEL needs driving this, so that every time we make a release that could plausibly need back ported fixes, we immediately branch and mark the CI infrastructure for preservation (and periodic CI validation tests?). Assuming we want to pay for so much infrastructure, that is — IIRC that was a concern at some point.

[cevich]

and periodic CI validation tests?

Technically the tests don't really even need to run. It's that "meta" task that's the important thing. At least that needs to run probably weekly, and be monitored (so we know if it stops running). I'm not worried about the infrastructure or cost (pennies) at all if it's important/critical to RHEL. It is an extra maintenance burden, but sometimes working CI for backports is necessary and important. I'm simply not qualified to be the judge of that.

Adding the e-mail monitoring is a pain, but it's a one-time up-front time-cost (unless it breaks).
Adding cron-jobs for new branches is trivial. It's just an entry in that web-form I linked.
REMEMBERING to add a new branch (and update .cirrus.yml) is the actual "hard" part 😜

[lsm5]

@mtrmac PTAL.

[lsm5]

ugh ..i thought i saw all green, nvm, looking ..

[mtrmac]

@lsm5 The keyring thing is probably fixed by backporting #1477 . The other failure looks like an infrastructure flake.

[lsm5]

Closing this in favour of #1542