[BUILD-2306] Hummingbird base image for operator

[adchauha]

Rebase operator Dockerfile to hi/go + hi/core-runtime.

[qodo-code-review]

PR Summary by Qodo

Build operator image on Hummingbird bases and update labels to el10

✨ Enhancement ⚙️ Configuration changes 🐞 Bug fix 🕐 20-40 Minutes

AI Description

• Rebase operator build/runtime images to Hummingbird (hi/go + hi/core-runtime)
• Enable FIPS runtime behavior and adjust Go build cache locations for non-root builds
• Update bundle/operator metadata to el10 and fix kube-rbac-proxy readOnlyRootFilesystem field

Diagram

graph TD
  A["Dockerfile"] --> B["Builder stage"] --> C["operator binary"] --> D["Operator runtime image"]
  E["bundle.Dockerfile"] --> F["Bundle metadata (el10)"]
  G["manager_auth_proxy_patch.yaml"] --> H["kube-rbac-proxy securityContext"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Builder-only Hummingbird, keep UBI minimal runtime

• ➕ Reduces runtime change surface while validating hi/go build compatibility
• ➕ May simplify runtime certification/compatibility concerns if UBI runtime is already proven
• ➖ Does not fully validate the intended Hummingbird runtime base transition
• ➖ Potential mismatch between build-time and runtime crypto/FIPS expectations

2. Rely on base-image defaults for FIPS, avoid app-level toggles

• ➕ Less application/container-specific behavior to maintain (e.g., no explicit GODEBUG)
• ➕ Avoids surprises if Go runtime flags evolve
• ➖ Harder to ensure FIPS behavior is consistently enforced across environments
• ➖ May require deeper verification of base-image configuration guarantees

3. Build in CI with explicit smoke checks (FIPS + execution) before merging

• ➕ Catches runtime/library/CGO issues introduced by base-image swap early
• ➕ Provides evidence for the POC’s viability (operator starts, endpoints reachable)
• ➖ Adds CI time/complexity and may require new test scaffolding

Recommendation: The chosen approach (switch both builder and runtime to Hummingbird and explicitly enable FIPS runtime behavior) is appropriate for a POC because it exercises the full target stack. Before treating this as production-ready, ensure CI validates the built image can start and that required crypto/FIPS expectations hold under the new base (CGO dependencies, filesystem permissions, and runtime libraries).

Files changed (3) +12 / -8

Bug fix (1) +1 / -1

manager_auth_proxy_patch.yamlFix kube-rbac-proxy readOnlyRootFilesystem securityContext key +1/-1

Fix kube-rbac-proxy readOnlyRootFilesystem securityContext key

• Corrects the securityContext field name to readOnlyRootFilesystem to enforce a read-only root filesystem for the kube-rbac-proxy container.

config/default/manager_auth_proxy_patch.yaml

Other (2) +11 / -7

DockerfileSwitch operator build/runtime stages to Hummingbird and enable FIPS +10/-6

Switch operator build/runtime stages to Hummingbird and enable FIPS

• Replaces the builder base with hi/go and the runtime base with hi/core-runtime. Adds non-root-friendly Go cache env vars, enables FIPS runtime behavior via GODEBUG, and updates image labels (CPE/name) from el9/rhel9 to el10/rhel10.

Dockerfile

bundle.DockerfileUpdate bundle CPE label from el9 to el10 +1/-1

Update bundle CPE label from el9 to el10

• Adjusts the bundle image CPE metadata to reflect el10 alignment.

bundle.Dockerfile

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0) 📜 Skill insights (0)

1. Cache copied into runtime 🐞 Bug ➹ Performance

Description

The builder stage now forces GOCACHE/GOMODCACHE under /opt/app-root/src, and the runtime stage
copies the entire /opt/app-root/src directory, so Go build cache (and possibly module cache) will be
shipped in the final operator image and increase image size.

Code

Dockerfile[R7-9]

+ENV HOME=/opt/app-root/src
+ENV GOCACHE=/opt/app-root/src/.cache/go-build
+ENV GOMODCACHE=/opt/app-root/src/.cache/go-mod

Evidence

The PR sets cache paths inside /opt/app-root/src and the runtime stage copies /opt/app-root/src
from the builder, which necessarily brings .cache/go-build (and any populated .cache/go-mod)
into the runtime image.

Dockerfile[7-9]
Dockerfile[26-27]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The final image includes build-time Go cache directories because the builder stage stores caches under `/opt/app-root/src` and the runtime stage copies `/opt/app-root/src` wholesale.

## Issue Context
This increases image size and ships non-runtime artifacts (e.g., `go-build` cache object files) into production images.

## Fix Focus Areas
- Dockerfile[7-9]
- Dockerfile[26-27]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. RHEL10 label/name mismatch 🐞 Bug ⚙ Maintainability

Description

The Dockerfile now labels the image as an el10/rhel10 operator, but the repo build configuration and
CSV/manifests still reference the rhel9 operator image name, leaving inconsistent image/product
metadata in the same release.

Code

Dockerfile[45]

+    name="openshift-builds/openshift-builds-rhel10-operator" \

Evidence

The PR changes the operator image labels to rhel10/el10, while the Makefile and CSV annotations
still point to the rhel9 operator image name, showing the naming transition is incomplete within
this repo.

Dockerfile[36-46]
Makefile[29-35]
bundle/manifests/openshift-builds-operator.clusterserviceversion.yaml[38-46]
config/manifests/bases/openshift-builds-operator.clusterserviceversion.yaml[9-16]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The operator image label metadata was updated to `...-rhel10-operator`/`el10`, but build and deployment metadata in-repo continues to use `...-rhel9-operator`, creating inconsistent product identifiers.

## Issue Context
This can cause confusion during release/certification and makes it unclear which image naming convention is authoritative.

## Fix Focus Areas
- Dockerfile[36-46]
- Makefile[29-35]
- bundle/manifests/openshift-builds-operator.clusterserviceversion.yaml[38-46]
- config/manifests/bases/openshift-builds-operator.clusterserviceversion.yaml[9-16]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}

[qodo-code-review]

1. Cache copied into runtime 🐞 Bug ➹ Performance

The builder stage now forces GOCACHE/GOMODCACHE under /opt/app-root/src, and the runtime stage
copies the entire /opt/app-root/src directory, so Go build cache (and possibly module cache) will be
shipped in the final operator image and increase image size.

Agent Prompt

## Issue description
The final image includes build-time Go cache directories because the builder stage stores caches under `/opt/app-root/src` and the runtime stage copies `/opt/app-root/src` wholesale.

## Issue Context
This increases image size and ships non-runtime artifacts (e.g., `go-build` cache object files) into production images.

## Fix Focus Areas
- Dockerfile[7-9]
- Dockerfile[26-27]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[qodo-code-review]

2. Rhel10 label/name mismatch 🐞 Bug ⚙ Maintainability

The Dockerfile now labels the image as an el10/rhel10 operator, but the repo build configuration and
CSV/manifests still reference the rhel9 operator image name, leaving inconsistent image/product
metadata in the same release.

Agent Prompt

## Issue description
The operator image label metadata was updated to `...-rhel10-operator`/`el10`, but build and deployment metadata in-repo continues to use `...-rhel9-operator`, creating inconsistent product identifiers.

## Issue Context
This can cause confusion during release/certification and makes it unclear which image naming convention is authoritative.

## Fix Focus Areas
- Dockerfile[36-46]
- Makefile[29-35]
- bundle/manifests/openshift-builds-operator.clusterserviceversion.yaml[38-46]
- config/manifests/bases/openshift-builds-operator.clusterserviceversion.yaml[9-16]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools