CNF-23203: Pin container image versions and add automated update workflow#1196
CNF-23203: Pin container image versions and add automated update workflow#1196sebrandon1 wants to merge 1 commit into
Conversation
Replace :latest tags with specific release versions in images.go. openscap-ocp and compliance-operator are pinned to v1.7.0 (the latest release with published container images). k8scontent is pinned to its current commit SHA since the content repo does not publish versioned image tags. Add a GitHub Actions workflow that runs daily to check for new releases, verify images exist in ghcr.io via skopeo, and open PRs to update the pinned versions. A shared script handles the backward search through releases for compliance-operator images. For k8scontent, the workflow inspects :latest to get the current revision SHA and updates if it has changed.
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: sebrandon1 The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Hi @sebrandon1. Thanks for your PR. I'm waiting for a ComplianceAsCode member to verify that this patch is reasonable to test. If it is, they should reply with Regular contributors should join the org to skip this step. Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
@sebrandon1: This pull request references CNF-23203 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "5.0.0" version, but no target version was set. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
🤖 To deploy this PR, run the following command: |
|
@yuumasato Could you please |
|
Verified that the pinned versions are still the latest published images. The v1.8.x releases exist on GitHub but none of them have container images pushed to GHCR yet: For k8scontent, the pinned commit All three pins are the latest available versions. |
All three container images in
pkg/utils/images.gowere hardcoded to:latest, which makes builds unreproducible — different clusters pulling at different times can silently get different content. This was flagged in ComplianceAsCode/content#14681.This PR:
openscap-ocpandcompliance-operatortov1.7.0(the latest release with published images in ghcr.io — note that v1.8.x releases exist but no corresponding container images were pushed)k8scontentto commit SHAb01ffe68cc1320ee472408798bc56d83cfbfb1f7(the revision behind the current:latesttag, since the content repo does not publish versioned image tags).github/workflows/update-image-versions.yml) that automatically opens PRs when new versions are availableThe workflow handles each image differently based on how they're published:
skopeo inspect). This gracefully handles releases that were tagged but never had images pushed.:latesttag'sorg.opencontainers.image.revisionlabel to get the current commit SHA, then pins to that SHA tag.The shared lookup logic lives in
.github/scripts/find-latest-image.shfor reuse.Note on
compliance-operatorself-reference: The operator uses its own image to spawn helper pods (profile parsers, scan workers, aggregators, etc.), which means there's an inherent chicken-and-egg issue — a new release will ship with the previous version pinned until the automated workflow opens a bump PR. In OLM deployments this doesn't matter sinceRELATED_IMAGE_OPERATORis set by the CSV. For non-OLM installs (Helm, raw manifests), theRELATED_IMAGE_*env vars can override all three defaults.As always, the
RELATED_IMAGE_*environment variables can still override these defaults at runtime.