containers / skopeo

Work with remote images registries - retrieving information, images, signing content
Apache License 2.0
7.75k stars 756 forks source link

chore(deps): update dependency containers/automation_images to v20240513 - autoclosed #2328

Closed renovate[bot] closed 1 month ago

renovate[bot] commented 1 month ago

Mend Renovate

This PR contains the following updates:

Package Update Change
containers/automation_images major 20240411t124913z-f39f38d13 -> 20240513t140131z-f40f39d13

Release Notes

containers/automation_images (containers/automation_images) ### [`v20240513t140131z-f40f39d13`](https://togithub.com/containers/automation_images/compare/20240320t153921z-f39f38d13...20240513t140131z-f40f39d13) [Compare Source](https://togithub.com/containers/automation_images/compare/20240320t153921z-f39f38d13...20240513t140131z-f40f39d13)

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

â™» Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.



This PR has been generated by Mend Renovate. View repository job log here.

packit-as-a-service[bot] commented 1 month ago

Ephemeral COPR build failed. @containers/packit-build please check.

edsantiago commented 1 month ago
    openshift.go:86: Log line: panic: encoding alphabet includes duplicate symbols

I can't tell if this is a bug in the new images, or a bug in something fetched from the net, or POM-dependent.

mtrmac commented 1 month ago

It’s true enough that https://github.com/openshift/origin/blob/cf7e336cb497b52d5034449f98e91382e4f36eb5/vendor/github.com/ugorji/go/codec/gen.go#L127 contains a duplicate character. The check was added in Go 1.22; if the image has updated from <1.22 to 1.22, I think that’s the explanation.

As for a path forward, patching that old version of OpenShift would not be unprecedented ( https://github.com/containers/automation_images/blob/b7395d11fee6e977d2256b536a485fdb9811839b/skopeo_cidev/setup.sh#L64-L69 ); https://github.com/ugorji/go/commit/8286c2dc986535d23e3fad8d3e816b9dd1e5aea6 seems like it might be a fix, I didn’t test that yet.

Ideally, we should either test with a recent version of OpenShift (but that would probably force us to stand up a ~real OpenShift cluster, running it as individual binaries the way we currently are is almost certainly no longer viable), or just stop testing atomic:; OpenShift changed the API in a way which completely breaks atomic: in any later version, so there’s not that much value in maintaining this part of the test. That would be at least a couple of days of work, atomic: is used in some signing tests we can’t just delete (but some are probably redundant).

cevich commented 1 month ago

or just stop testing atomic:; OpenShift changed the API in a way which completely breaks atomic: in any later version, so there’s not that much value in maintaining this part of the test.

(Drive-by-comment)

It's been a few years, but IIRC there were quite a number of high-level CI setup/operation compromises made to support testing w/ the old OpenShift. It's possible if that testing went away, the CI setup could also be simplified. Implying an improvement to CI testing reliability and ease of maintenance.

mtrmac commented 1 month ago

I think removing the atomic: tests and the old OpenShift build would be a worthwhile project, but short-term I’d rather try the smaller fix, so that we are not blocked from using Go 1.22 for other reasons.

Let’s see if https://github.com/containers/automation_images/pull/355 helps.