fix(workflows): stop collapsing base images to single-arch during release - #1067
Conversation
…lti-arch manifest crane mutate on a manifest list only pulls the default-platform (amd64) child image and pushes it back, overwriting the multi-arch index with a single-arch image. Remove the post-build label step (and the unused manifest-tool setup) so base images stay multi-arch; version labels are inherited from the base image.
![ti-chi-bot[bot]](https://avatars.githubusercontent.com/in/214286?s=60&v=4){kind=small}
There was a problem hiding this comment.
I have already done a preliminary review for you, and I hope to help you do a better job.
Summary:
This PR removes the setup of manifest-tool and the step that sets image version labels using crane mutate in the GitHub Actions workflow for releasing production runtime images. The intent is to prevent collapsing base images into single-architecture manifests during release. The approach is straightforward by deleting the related steps. Overall, the changes are minimal and clearly target the problem, but there are some implications and risks to consider regarding image labeling and manifest handling.
Critical Issues
- Potential loss of image version labels (File:
.github/workflows/release-prod-runtime-images.yaml, lines ~81-98)
Removing the "Set image version labels" step means the base images will no longer have theorg.opencontainers.image.versionandversionlabels set or updated during the release workflow. This could impact image traceability, versioning, and tooling that relies on these labels.
Suggestion: Instead of fully removing this step, consider modifying it to work correctly with multi-arch images or alternative tooling, or ensure the labeling is handled elsewhere in the pipeline.
Code Improvements
- Remove unused
manifest-toolsetup cleanly (File:.github/workflows/release-prod-runtime-images.yaml, lines ~53-59)
Themanifest-toolsetup is removed, but there is no replacement step for manifest handling or validation. If the intent is to stop collapsing to single-arch manifests, this is fine, but confirm that the manifest publishing logic still meets requirements.
Suggestion: Add a comment explaining whymanifest-toolis removed and how manifests are handled now, to help future maintainers understand the rationale.
Best Practices
-
Add comments explaining removal rationale (File:
.github/workflows/release-prod-runtime-images.yaml)
The PR lacks any comments or documentation explaining why these steps were removed. This makes it harder to understand the impact and reasoning from the workflow file alone.
Suggestion: Add inline comments or a README update clarifying that collapsing base images to single-arch manifests is no longer desired, and thus these steps were removed. -
Testing coverage for multi-arch support
It is unclear if there is automated testing or workflow runs validating that after this change, the release images are correctly multi-arch and properly labeled.
Suggestion: Ensure there is a test or manual verification documented that confirms the new workflow behavior produces the expected multi-arch images with correct metadata.
Summary of actionable steps:
- Reconsider the removal of the "Set image version labels" step or replace it with a multi-arch compatible versioning approach to preserve image metadata.
- Add comments in the workflow file explaining why `manifest-tool` and the labeling step are removed, to clarify the intent.
- Confirm and document how manifests are now handled and how image versioning is ensured post-change.
- Add or update tests/verification steps to ensure multi-arch images are published correctly with expected labels.
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: wuhuizuo The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
1 participant
No description provided.