Skip to content

CNF-23203: Pin container image versions and add automated update workflow#1196

Open
sebrandon1 wants to merge 1 commit into
ComplianceAsCode:masterfrom
sebrandon1:lock-image-versions
Open

CNF-23203: Pin container image versions and add automated update workflow#1196
sebrandon1 wants to merge 1 commit into
ComplianceAsCode:masterfrom
sebrandon1:lock-image-versions

Conversation

@sebrandon1
Copy link
Copy Markdown

All three container images in pkg/utils/images.go were 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:

  • Pins openscap-ocp and compliance-operator to v1.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)
  • Pins k8scontent to commit SHA b01ffe68cc1320ee472408798bc56d83cfbfb1f7 (the revision behind the current :latest tag, since the content repo does not publish versioned image tags)
  • Adds a daily GitHub Actions workflow (.github/workflows/update-image-versions.yml) that automatically opens PRs when new versions are available

The workflow handles each image differently based on how they're published:

  • openscap-ocp / compliance-operator: Searches backwards through compliance-operator GitHub releases to find the newest one where both images exist in ghcr.io (via skopeo inspect). This gracefully handles releases that were tagged but never had images pushed.
  • k8scontent: Inspects the :latest tag's org.opencontainers.image.revision label to get the current commit SHA, then pins to that SHA tag.

The shared lookup logic lives in .github/scripts/find-latest-image.sh for reuse.

Note on compliance-operator self-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 since RELATED_IMAGE_OPERATOR is set by the CSV. For non-OLM installs (Helm, raw manifests), the RELATED_IMAGE_* env vars can override all three defaults.

As always, the RELATED_IMAGE_* environment variables can still override these defaults at runtime.

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.
@openshift-ci
Copy link
Copy Markdown

openshift-ci Bot commented Apr 27, 2026

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: sebrandon1
Once this PR has been reviewed and has the lgtm label, please assign taimurhafeez for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci
Copy link
Copy Markdown

openshift-ci Bot commented Apr 27, 2026

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 /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

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 kubernetes-sigs/prow repository.

@sebrandon1 sebrandon1 changed the title Pin container image versions and add automated update workflow CNF-23203: Pin container image versions and add automated update workflow Apr 27, 2026
@openshift-ci-robot
Copy link
Copy Markdown
Collaborator

@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.

Details

In response to this:

All three container images in pkg/utils/images.go were 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:

  • Pins openscap-ocp and compliance-operator to v1.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)
  • Pins k8scontent to commit SHA b01ffe68cc1320ee472408798bc56d83cfbfb1f7 (the revision behind the current :latest tag, since the content repo does not publish versioned image tags)
  • Adds a daily GitHub Actions workflow (.github/workflows/update-image-versions.yml) that automatically opens PRs when new versions are available

The workflow handles each image differently based on how they're published:

  • openscap-ocp / compliance-operator: Searches backwards through compliance-operator GitHub releases to find the newest one where both images exist in ghcr.io (via skopeo inspect). This gracefully handles releases that were tagged but never had images pushed.
  • k8scontent: Inspects the :latest tag's org.opencontainers.image.revision label to get the current commit SHA, then pins to that SHA tag.

The shared lookup logic lives in .github/scripts/find-latest-image.sh for reuse.

Note on compliance-operator self-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 since RELATED_IMAGE_OPERATOR is set by the CSV. For non-OLM installs (Helm, raw manifests), the RELATED_IMAGE_* env vars can override all three defaults.

As always, the RELATED_IMAGE_* environment variables can still override these defaults at runtime.

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.

@github-actions
Copy link
Copy Markdown

🤖 To deploy this PR, run the following command:

make catalog-deploy CATALOG_IMG=ghcr.io/complianceascode/compliance-operator-catalog:1196-424d289854e71927463d881711389f21322fb28f

@sebrandon1
Copy link
Copy Markdown
Author

@yuumasato Could you please /ok-to-test this PR when you get a chance? Thanks!

@sebrandon1
Copy link
Copy Markdown
Author

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 tag in v1.8.2 v1.8.1 v1.8.0; do
    echo "=== $tag ==="
    echo -n "openscap-ocp: "
    skopeo inspect --override-arch amd64 --override-os linux "docker://ghcr.io/complianceascode/openscap-ocp:${tag}" > /dev/null 2>&1 && echo "EXISTS" || echo "MISSING"
    echo -n "compliance-operator: "
    skopeo inspect --override-arch amd64 --override-os linux "docker://ghcr.io/complianceascode/compliance-operator:${tag}" > /dev/null 2>&1 && echo "EXISTS" || echo "MISSING"
  done

=== v1.8.2 ===
openscap-ocp: MISSING
compliance-operator: MISSING
=== v1.8.1 ===
openscap-ocp: MISSING
compliance-operator: MISSING
=== v1.8.0 ===
openscap-ocp: MISSING
compliance-operator: MISSING

For k8scontent, the pinned commit b01ffe68cc1320ee472408798bc56d83cfbfb1f7 matches what :latest currently resolves to, so that's current too.

All three pins are the latest available versions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants