Use Quay.io Konflux dev images in upstream bundle

[yuumasato]

Summary

Update the upstream bundle manifests to reference Quay.io Konflux dev images with :master tags instead of GitHub Container Registry images. This ensures the upstream catalog always uses the latest Konflux builds from master.

Changes

• Update bundle/manifests/compliance-operator.clusterserviceversion.yaml to use quay.io/redhat-user-workloads/ocp-isc-tenant/*-dev:master images
• Re-add bundle build job to .github/workflows/release-latest.yml
• Catalog job now depends on the bundle job and uses the GitHub-built bundle (which contains quay.io references)

Flow

1. Konflux builds operator/openscap/content/must-gather images, tags with :master
2. GitHub Actions builds bundle from updated manifests → ghcr.io/complianceascode/compliance-operator-bundle:latest
3. GitHub Actions builds catalog from bundle → ghcr.io/complianceascode/compliance-operator-catalog:latest
4. E2e tests install from catalog and get the latest Konflux :master images

Benefits

• Version-agnostic: Works on any OCP cluster version
• Always latest: E2e tests always use most recent Konflux builds from master
• Simple: Just manifest changes, no Konflux pipeline modifications needed

Test plan

After merge and workflow runs:

1. Extract and verify bundle references quay.io:

   oc image extract ghcr.io/complianceascode/compliance-operator-bundle:latest --confirm
   grep "image:" manifests/*.clusterserviceversion.yaml | grep quay.io

2. Deploy operator and verify it uses quay.io images:

   oc apply -f ~/git/content/ocp-resources/compliance-operator-catalog-source.yaml
   oc create -f ocp-resources/compliance-operator-ns.yaml
   oc create -f ocp-resources/compliance-operator-operator-group.yaml
   oc create -f ocp-resources/compliance-operator-alpha-subscription.yaml
   oc get deployment -n openshift-compliance compliance-operator -o yaml | grep image:

🤖 Generated with Claude Code

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: yuumasato

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [yuumasato]

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

[github-actions]

🤖 To deploy this PR, run the following command:

make catalog-deploy CATALOG_IMG=ghcr.io/complianceascode/compliance-operator-catalog:1295-7f4d4a053ed11aafcb69c721783730575d89f329

[yuumasato]

Context: Why this change is needed

Problem with ocp4e2e and content repos

The e2e test infrastructure critically depends on the catalog defined in the content repo. When ocp4e2e installs the operator, it uses the CatalogSource from content upstream, which points to:

image: ghcr.io/complianceascode/compliance-operator-catalog:latest

The critical issue: This catalog was built from a bundle that referenced outdated GitHub Container Registry images, particularly the content image ghcr.io/complianceascode/k8scontent:latest.

When developers make changes to compliance rules/profiles in the content repo and want to test them via ocp4e2e, the catalog was still deploying the stale GitHub Actions-built content image instead of the latest Konflux build from master. This meant:

1. E2e tests weren't testing latest content: Changes to compliance rules/profiles weren't reflected in test runs
2. Development friction: No automatic way to verify content changes without manual image building
3. Duplicate/divergent builds: Konflux was building the authoritative images, but e2e used different ones from GitHub Actions
4. Version lock-in: The catalog couldn't be used across different OCP cluster versions

The solution

This PR updates the bundle manifests to reference Quay.io Konflux dev images with :master tags:

• quay.io/redhat-user-workloads/ocp-isc-tenant/compliance-operator-content-dev:master (the key fix)
• quay.io/redhat-user-workloads/ocp-isc-tenant/compliance-operator-dev:master
• quay.io/redhat-user-workloads/ocp-isc-tenant/compliance-operator-openscap-dev:master

These images are automatically updated by Konflux on every merge to master in both the compliance-operator and content repos.

Result: E2e tests in ocp4e2e now automatically use the latest content changes from master, making content development testable immediately and the catalog version-agnostic across OCP versions.

[openshift-ci]

@yuumasato: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/e2e-aws-parallel	7f4d4a0	link	true	/test e2e-aws-parallel

Full PR test history. Your PR dashboard.

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. I understand the commands that are listed here.

[abushkin-redhat]

Hey @yuumasato, looks great! A couple of findings from Claude's /code-review:

1. bundle-hack/update_csv.go:209,215 — In replaceImages(), the contentImage fields in alm-examples are set to newPullSpecs["RELATED_IMAGE_OPERATOR"] instead of newPullSpecs["RELATED_IMAGE_PROFILE"]. This means downstream bundle builds would have the CSV examples pointing to the operator image rather than the content image, which would cause profile parsing failures if anyone copies those examples.
2. config/manager/deployment.yaml:55-59 and pkg/utils/images.go:17-19 — The PR removes the GHCR push workflows for operator, openscap, and must-gather, but config/manager/deployment.yaml (used by make deploy-local) and the hardcoded fallback defaults in pkg/utils/images.go still reference ghcr.io/complianceascode/*:latest. Once the workflows are gone, these images will stop receiving updates, so local dev deployments and any edge case where RELATED_IMAGE_* env vars are unset will silently use stale images. The base CSV template at config/manifests/bases/compliance-operator.clusterserviceversion.yaml has the same issue.
3. tests/e2e/cel_tests/main_test.go:1018,1052 — In TestCustomRuleCascadingStatusUpdate, the CEL expression checks pod.spec.securityContext.runAsNonRoot == true but the FailureReason says "Pod(s) found without resource limits" and the TailoredProfile rationale says "Pods should have resource limits for stability" — looks like a copy-paste from a different rule.
4. Makefile:643 — The e2e-cel target's help comment says "Run profile parsing end-to-end tests" — copy-pasted from the e2e-parsing target above it. Should say something like "Run CEL CustomRule end-to-end tests".