k8scontent container images missing for v0.1.79 and v0.1.80 releases

[sebrandon1]

Summary

The ghcr.io/complianceascode/k8scontent container image does not have tags corresponding to the v0.1.79 and v0.1.80 releases. The :latest tag is pinned to a June 2025 build (commit b01ffe68cc1320ee472408798bc56d83cfbfb1f7), which predates both releases.

Evidence

# :latest is from June 2025 — predates v0.1.78 (Sep 2025), v0.1.79 (Nov 2025), v0.1.80 (Mar 2026)
$ skopeo inspect --override-arch amd64 --override-os linux docker://ghcr.io/complianceascode/k8scontent:latest
  "Created": "2025-06-13T17:17:53.170052561Z"
  "org.opencontainers.image.revision": "b01ffe68cc1320ee472408798bc56d83cfbfb1f7"

# No version-tagged images exist
$ skopeo inspect docker://ghcr.io/complianceascode/k8scontent:v0.1.79
  name unknown: repository not found

$ skopeo inspect docker://ghcr.io/complianceascode/k8scontent:v0.1.80
  name unknown: repository not found

Impact

The compliance-operator references k8scontent:latest in its deployment manifest via RELATED_IMAGE_PROFILE. Since :latest hasn't been updated since June 2025:

1. Scan results are not reproducible — different clusters pulling :latest at different times could get different content if the tag ever updates
2. New features are unavailable — v0.1.80 added sshd_runtime_check for RHCOS (products/rhcos4/product.yml), but no cluster using the published images will have it
3. No way to pin to a release — without version-tagged images, users cannot reference a specific content release for reproducibility

Request

1. Publish ghcr.io/complianceascode/k8scontent:v0.1.79 and ghcr.io/complianceascode/k8scontent:v0.1.80 images
2. Update :latest to point to the current release (v0.1.80) — the compliance-operator defaults to :latest when RELATED_IMAGE_PROFILE is not overridden
3. Consider publishing version-tagged images as part of the release process going forward (the Dockerfiles/ocp4_content Dockerfile already exists for this purpose)

[sebrandon1]

Just as a note I'm publishing my own images (amd64, arm64) via my compliance-scripts repo:

• https://quay.io/repository/bapalm/k8scontent
• https://quay.io/repository/bapalm/openscap-ocp
• https://quay.io/repository/bapalm/compliance-operator
• https://quay.io/repository/bapalm/compliance-operator-bundle
• https://quay.io/repository/bapalm/compliance-operator-catalog

These should mirror the releases of these various images built from source.

[sebrandon1]

Status update: issue still present (verified 2026-05-20)

Rechecked with skopeo v1.22.2:

# :latest is still pinned to June 2025
$ skopeo inspect --override-arch amd64 --override-os linux docker://ghcr.io/complianceascode/k8scontent:latest \
  | jq '{Created, revision: .Labels["org.opencontainers.image.revision"]}'
{
  "Created": "2025-06-13T17:17:53.170052561Z",
  "revision": "b01ffe68cc1320ee472408798bc56d83cfbfb1f7"
}

# v0.1.79 still missing
$ skopeo inspect docker://ghcr.io/complianceascode/k8scontent:v0.1.79
FATA[...] manifest unknown

# v0.1.80 still missing
$ skopeo inspect docker://ghcr.io/complianceascode/k8scontent:v0.1.80
FATA[...] manifest unknown

The latest release is v0.1.80 (2026-03-06), making :latest now ~11 months stale. Only commit-SHA and sigstore attestation tags are published — no version tags exist.

[yuumasato]

I'm not sure what was tagging the k8scontent image with the release versions, but it was being built by workflows that were removed here: #13567

But moving forward we should be using the images built by the tekton pipelines:

content/.tekton/compliance-operator-content-dev-push.yaml

Line 26 in f8760a0

value: quay.io/redhat-user-workloads/ocp-isc-tenant/compliance-operator-content-dev:{{revision}}

[sebrandon1]

That's fine but the code in https://github.com/ComplianceAsCode/compliance-operator/blob/master/pkg/utils/images.go is still using the old locations?