Removing installation of CA

[lipoja]

Certificate is inaccessible.

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 2:55 PM UTC · Completed 3:03 PM UTC
Commit: 8207ad4 · View workflow run →

[qodo-for-releng]

PR Summary by Qodo

Split IIB worker tooling into a shared base image and add main-branch build workflows
✨ Enhancement ⚙️ Configuration changes 📝 Documentation 🕐 40+ Minutes

Description

• Introduce a shared iib-base-image Dockerfile and make the worker build FROM it.
• Add GitHub Actions workflows to build/push iib-base-image:latest and *:ocp-latest on main.
• Update local compose/Makefile and docs to reflect the new build order and bootstrap steps.

Diagram

graph TD
  A["GitHub: build_on_main.yml"] --> B["Detect Dockerfile change"] --> C["GitHub: build_base_image.yml"] --> D["Build "docker/Dockerfile-base-image""] --> E[("Quay: iib-base-image:latest")]
  A --> F["Build "docker/Dockerfile-api""] --> G[("Quay: iib-api:ocp-latest")]
  A --> H["Build "docker/Dockerfile-workers""] --> I[("Quay: iib-worker:ocp-latest")]
  E --> H

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Pin worker base image by digest (or versioned tag) instead of :latest

• ➕ Improves reproducibility and prevents accidental regressions from base-image churn
• ➕ Avoids reliance on workflow ordering to prevent stale pulls
• ➖ Requires a mechanism to propagate the new digest/tag into Dockerfile-workers or build args
• ➖ Slightly more CI complexity (e.g., outputs, metadata, or templating)

2. Build base + worker in one workflow run without pushing an intermediate :latest

• ➕ Eliminates cross-job registry race conditions entirely
• ➕ Keeps intermediate layers private to CI unless explicitly released
• ➖ Makes the base image less reusable across pipelines and local builds
• ➖ Harder to share cached layers across separate workflows/runs

3. Use Buildah/Buildx cache-to-registry with immutable cache keys

• ➕ Keeps a single Dockerfile while still improving build speed
• ➕ Avoids maintaining multiple Dockerfiles for shared tooling
• ➖ Cache configuration is easy to misconfigure and can be flaky across runners
• ➖ Does not provide the same clear artifact boundary as a published base image

Recommendation: The split base-image approach is sound for this repo (heavy tooling layer, worker-specific Python on top) and the CI orchestration correctly avoids building workers against a stale Quay tag. If this becomes a reliability issue, the best next step would be to pin the base image by digest (or publish a unique, immutable tag per base-image build) to remove remaining :latest ambiguity while keeping the reuse benefits.

Files changed (9) +323 / -71

Refactor (1) +14 / -69

Dockerfile-workersRefactor worker Dockerfile to build FROM shared base image +14/-69

Refactor worker Dockerfile to build FROM shared base image

• Switches the worker image to build FROM a BASE_IMAGE argument (defaulting to the Quay base image) and removes duplicated tooling installation. Also improves dependency layer caching by copying lockfiles first and then copying the 'iib/' package source before installing.

docker/Dockerfile-workers

Documentation (2) +37 / -1

AGENTS.mdDocument new production image sources and base-image split +1/-1

Document new production image sources and base-image split

• Updates the production build description to reference the new docker/Dockerfile-base-image and Quay-published base layer used by the worker image.

AGENTS.md

README.mdAdd container image architecture and CI bootstrap docs +36/-0

Add container image architecture and CI bootstrap docs

• Documents the new base-image/worker layering, local build behavior (iib-base-image:local), and the one-time CI bootstrap requirement to seed Quay with iib-base-image:latest.

README.md

Other (6) +272 / -1

build_base_image.ymlAdd reusable workflow to build/push iib-base-image +54/-0

Add reusable workflow to build/push iib-base-image

• Introduces a workflow_call/workflow_dispatch GitHub Actions workflow that builds the shared base image from docker/Dockerfile-base-image and pushes it to quay.io using registry secrets.

.github/workflows/build_base_image.yml

build_on_main.ymlAdd main-branch image build pipeline with base-image gating +113/-0

Add main-branch image build pipeline with base-image gating

• Adds a push-to-main workflow that (1) detects whether the base Dockerfile changed, (2) conditionally rebuilds/pushes the base image, and (3) builds/pushes iib-api and iib-worker as ocp-latest with the worker waiting on the base job when applicable.

.github/workflows/build_on_main.yml

MakefileBuild base image before worker/api in local dev +2/-1

Build base image before worker/api in local dev

• Adjusts the build target to build the iib-base-image first and then build the application images, matching the new two-stage worker build model.

Makefile

docker-compose.ymlAdd local iib-base-image build service and worker build arg +10/-0

Add local iib-base-image build service and worker build arg

• Adds a build-only iib-base-image service producing iib-base-image:local and configures iib-worker to build using BASE_IMAGE=iib-base-image:local.

compose-files/docker-compose.yml

podman-compose.ymlMirror docker-compose base-image service for podman-compose +10/-0

Mirror docker-compose base-image service for podman-compose

• Adds the same build-only iib-base-image service and sets the worker BASE_IMAGE build arg for the podman-compose workflow.

compose-files/podman-compose.yml

Dockerfile-base-imageIntroduce shared tooling base image for worker builds +83/-0

Introduce shared tooling base image for worker builds

• Creates a new Dockerfile that installs container tooling and build dependencies (buildah/podman/skopeo, oc client, opm variants, operator-sdk, grpcurl, etc.) and configures python alternatives and container storage settings for downstream worker builds.

docker/Dockerfile-base-image

[fullsend-ai-review]

Review skipped — this PR is already merged.

The /fs-review command only reviews open pull requests.

_{Posted by fullsend post-review check}

[qodo-for-releng]

Code Review by Qodo

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

1. Outdated CA documentation 🐞 Bug ⚙ Maintainability

Description

The PR removes installation of the corporate Red Hat root CA in the worker base image, but README.md
still states docker/Dockerfile-base-image includes “Red Hat CA certificates”, which is now false and
can mislead users about expected TLS trust behavior.

Code

docker/Dockerfile-base-image[L85-89]

-RUN set -eux; \
-    curl -fsSL "https://certs.corp.redhat.com/certs/2022-IT-Root-CA.pem" \
-      -o /etc/pki/ca-trust/source/anchors/2022-IT-Root-CA.pem; \
-    echo "e9713aed04b4ef3003edd10fc9c4f8ab875436e4a44195f0cbafcdf95e9bad2c  /etc/pki/ca-trust/source/anchors/2022-IT-Root-CA.pem" | sha256sum -c -; \
-    update-ca-trust

Relevance

⭐⭐⭐ High

Team often updates README alongside behavior/config changes; README updates included in PRs #1181,
#1107, #1036.

PR-#1181
PR-#1107
PR-#1036

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

README.md explicitly claims the base image provides “Red Hat CA certificates”, but the current
docker/Dockerfile-base-image (post-PR) contains no CA installation step and ends after copying
libpod.conf.

README.md[93-101]
docker/Dockerfile-base-image[1-83]

Agent prompt

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

### Issue description
`docker/Dockerfile-base-image` no longer installs the corporate Red Hat CA (the `curl ... 2022-IT-Root-CA.pem` + `update-ca-trust` block was removed), but the documentation still claims this image includes “Red Hat CA certificates”. This creates documentation drift and incorrect operator expectations.

### Issue Context
The base image is described in the main README under “Container Images”. After this PR, the Dockerfile contains no step that installs that corporate CA / runs `update-ca-trust`.

### Fix Focus Areas
- README.md[93-101]
- docker/Dockerfile-base-image[1-83]

### Suggested change
Update the README entry for `docker/Dockerfile-base-image` to remove/adjust the “Red Hat CA certificates” claim, or explicitly document the new intended CA injection mechanism (e.g., mounting a CA bundle at runtime in deployment/compose).

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

---