Following the invitation in #144, I would like to add a small metadata check for the operator image referenced by the rendered installation bundle. I maintain kube-image-preflight, the checker discussed there.
Proposed first step
A manually dispatched workflow taking an explicit, already-published candidate image reference:
- Resolve a supplied tag once to an immutable digest, then use that same digest throughout the run.
- Reuse
make release-manifest IMG=<repository>@sha256:<digest> to render install.yaml, covering both the controller Deployment and daemon DaemonSet.
- Check
linux/amd64 and linux/arm64 independently using a version-pinned checker. Keep the rendered bundle and per-platform JSON reports, including on failure.
- Missing platform, unresolved metadata, or rendering/setup errors fail the run. The report should identify the affected workload/container and distinguish missing metadata from an unavailable registry.
Validation should include an amd64-only image (amd64 passes; arm64 fails for both workloads), a multi-arch image (both pass), and registry/rendering failures. This is a proposed workflow; it has not been implemented or exercised in this repository.
Publishing integration
Current main still builds the native runner architecture, and #145 remains open, so I propose starting with an explicit manual check rather than requiring arm64 on every existing build. Checking a moving latest tag in a PR would test an earlier published image, not the PR candidate.
For subsequent automatic integration, there are two publishing paths: ci.yaml's push job and the independent build/push in release.yaml. #145 currently changes only the former. Both paths need to be considered before treating this as a release gate.
This checks registry metadata only; it does not establish Arm runtime support or replace the bink/e2e work discussed in #145. It would not build or publish images.
Would this manual first step with the pinned Python/Buildx checker fit the project, or would you prefer a check using the existing registry tooling? I can take the small workflow once that scope is agreed.
Generated-by: AI
Following the invitation in #144, I would like to add a small metadata check for the operator image referenced by the rendered installation bundle. I maintain kube-image-preflight, the checker discussed there.
Proposed first step
A manually dispatched workflow taking an explicit, already-published candidate image reference:
make release-manifest IMG=<repository>@sha256:<digest>to renderinstall.yaml, covering both the controller Deployment and daemon DaemonSet.linux/amd64andlinux/arm64independently using a version-pinned checker. Keep the rendered bundle and per-platform JSON reports, including on failure.Validation should include an amd64-only image (amd64 passes; arm64 fails for both workloads), a multi-arch image (both pass), and registry/rendering failures. This is a proposed workflow; it has not been implemented or exercised in this repository.
Publishing integration
Current
mainstill builds the native runner architecture, and #145 remains open, so I propose starting with an explicit manual check rather than requiring arm64 on every existing build. Checking a movinglatesttag in a PR would test an earlier published image, not the PR candidate.For subsequent automatic integration, there are two publishing paths:
ci.yaml'spushjob and the independent build/push inrelease.yaml. #145 currently changes only the former. Both paths need to be considered before treating this as a release gate.This checks registry metadata only; it does not establish Arm runtime support or replace the bink/e2e work discussed in #145. It would not build or publish images.
Would this manual first step with the pinned Python/Buildx checker fit the project, or would you prefer a check using the existing registry tooling? I can take the small workflow once that scope is agreed.
Generated-by: AI