chore(ci): multi-arch e2e-runner image & add oc-mirror and podman

[zdrapela]

Make the e2e-runner container image buildable for both linux/amd64 and linux/arm64, and add tools required for disconnected environment smoke tests.

Dockerfile

• Add podman and oc-mirror to the image (required for disconnected env. smoke test)
• Update oc to 4.22
• Pin base image to manifest list digest (resolves per-platform, Renovate-compatible)
• Add ARG TARGETARCH — all tool downloads use it instead of hardcoded amd64/x86_64
• Upgrade umoci v0.4.7 → v0.6.0 (first version with arm64 binaries)
• Remove unused Go env vars (GO_VERSION, GO_SHA256, GOPATH)
• Clean up AWS CLI install artifacts (rm -rf awscliv2.zip aws/)
• Add apt-get clean to skopeo/podman install step

CI Workflow

• Add matrix strategy: ubuntu-24.04 (amd64) + ubuntu-24.04-arm (arm64)
• New merge job assembles per-arch digests into a multi-arch manifest list
• Add pull_request trigger — builds both platforms (without pushing) on Dockerfile/yarnrc changes to catch build failures before merge
• Push-only steps (login, digest export, merge) guarded with if: github.event_name != 'pull_request'
• Detect platform via dpkg --print-architecture instead of mapping runner label names
• Add HAS_QUAY_AUTH guard, timeout-minutes: 120, pin merge runner to ubuntu-24.04
• Widen branch glob from release-1.* to release-* for future major versions

local-run.sh

• Remove --platform=linux/amd64 from podman pull (auto-detects host arch)

Verified locally

Both images built and all tools (helm, oc, oc-mirror, ocm, yq, aws, az, gcloud, umoci, opm, operator-sdk, node, yarn, psql, skopeo, podman) confirmed working on both architectures.

https://redhat.atlassian.net/browse/RHIDP-13974

[rhdh-qodo-merge]

PR Summary by Qodo

chore(ci): make e2e-runner image builds multi-arch (amd64 + arm64)

✨ Enhancement ⚙️ Configuration changes 🕐 20-40 Minutes

AI Description

• Pin Playwright base image to a multi-arch manifest digest.
• Parameterize tool downloads via TARGETARCH for amd64/arm64 builds.
• Let local-run podman pull auto-select the host architecture.

Diagram

graph TD
  A["CI / Developer"] --> B["buildx / podman build"] --> C[".ci/images/Dockerfile"] --> D["TARGETARCH (amd64/arm64)"] --> E["Arch-aware tool downloads"] --> F["e2e-runner image"]
  G["e2e-tests/local-run.sh"] --> H["podman pull runner image"] --> F

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Use TARGETPLATFORM + explicit mapping

• ➕ More future-proof (handles platform variants like linux/arm/v7)
• ➕ Avoids assuming TARGETARCH strings match upstream naming schemes
• ➖ Slightly more scripting/branching in the Dockerfile
• ➖ No immediate benefit if only amd64/arm64 are required

2. Switch more tools to distro packages where available

• ➕ Reduces curl-install surface area and arch-specific URL handling
• ➕ Lets apt resolve architecture automatically
• ➖ Versions may lag compared to pinned upstream releases
• ➖ Some tools (oc/oc-mirror/opm) are not reliably available via apt with desired versions

Recommendation: The PR’s approach (TARGETARCH-driven URLs + targeted special-casing for oc/oc-mirror and AWS CLI naming) is the best fit for the current goal of amd64+arm64 support while keeping versions pinned. Consider TARGETPLATFORM mapping only if additional architectures/variants become a requirement.

Files changed (2) +35 / -27

Other (2) +35 / -27

DockerfileMake tool installs architecture-aware for multi-arch e2e-runner builds +34/-26

Make tool installs architecture-aware for multi-arch e2e-runner builds

• Pins the Playwright base image to a manifest-list digest and introduces TARGETARCH to drive architecture-specific downloads. Updates oc to 4.22.3, adds oc-mirror, upgrades umoci to v0.6.0 for arm64 support, and switches multiple tool URLs (helm/oc/ocm/yq/opm) to use the resolved architecture. Also removes unused Go-related env vars and installs podman alongside skopeo.

.ci/images/Dockerfile

local-run.shStop forcing amd64 when pulling the runner image locally +1/-1

Stop forcing amd64 when pulling the runner image locally

• Removes the explicit --platform=linux/amd64 flag from podman pull so the correct image variant is selected automatically on arm64 and amd64 hosts.

e2e-tests/local-run.sh

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 54.77%. Comparing base (a1a8bf9) to head (524341e).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5036      +/-   ##
==========================================
- Coverage   55.39%   54.77%   -0.62%     
==========================================
  Files         122      110      -12     
  Lines        2365     2147     -218     
  Branches      562      541      -21     
==========================================
- Hits         1310     1176     -134     
+ Misses       1048      969      -79     
+ Partials        7        2       -5     

Flag	Coverage Δ
rhdh	54.77% <ø> (-0.62%)	⬇️

---

Continue to review full report in Codecov by Harness.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a1a8bf9...524341e. Read the comment docs.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

The container image build workflow finished with status: cancelled.

[github-actions]

The container image build workflow finished with status: cancelled.

[github-actions]

The container image build workflow finished with status: cancelled.

[github-actions]

The container image build workflow finished with status: cancelled.

[rhdh-qodo-merge]

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. TARGETARCH may be unset 🐞 Bug ☼ Reliability

Description

.ci/images/Dockerfile uses ${TARGETARCH} directly in multiple download URLs/paths, but `ARG
TARGETARCH has no fallback; builds that don’t inject TARGETARCH` will generate invalid URLs like
linux-.tar.gz and fail. This is especially likely for the repo-documented podman build ...
command, which does not pass --platform/--build-arg.

Code

.ci/images/Dockerfile[R6-7]

+# Automatically set by buildx/podman based on --platform (amd64 or arm64)
+ARG TARGETARCH

Relevance

⭐⭐ Medium

No prior reviews on TARGETARCH fallback; only general Dockerfile reliability fixes accepted (digest
pinning).

PR-#4575

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The Dockerfile declares ARG TARGETARCH without a default and later interpolates it into multiple
download URLs and paths; the repo’s build instructions show podman build without any
--platform/--build-arg, so TARGETARCH may be empty in that flow, causing broken URLs like
...linux-.tar.gz.

.ci/images/Dockerfile[6-72]
.ci/images/README[40-46]

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 Dockerfile assumes `TARGETARCH` is always provided by the builder, but the repo’s documented build flow uses plain `podman build` (no `--platform` / `--build-arg`). When `TARGETARCH` is empty, several downloads reference invalid URLs/paths and the build fails.

## Issue Context
- `ARG TARGETARCH` is declared but not defaulted.
- Multiple tool downloads use `${TARGETARCH}` in URLs and in extracted directory names.
- `.ci/images/README` documents a plain `podman build ... -f .ci/images/Dockerfile .` command.

## Fix Focus Areas
- Add a robust fallback for `TARGETARCH` (e.g., derive from `dpkg --print-architecture` when `TARGETARCH` is empty) and use that derived value consistently in the tool-download `RUN` blocks.
- Optionally update `.ci/images/README` to document `--platform` / `--build-arg TARGETARCH=...` for reproducibility.

### Suggested implementation sketch
In the tool install `RUN` block(s), compute a local variable:
```sh
ARCH="${TARGETARCH:-$(dpkg --print-architecture)}"
```
…and replace `linux-${TARGETARCH}` with `linux-${ARCH}`, and the `arm64` comparisons to use `${ARCH}`.

## Fix Focus Areas (exact locations)
- .ci/images/Dockerfile[6-72]
- .ci/images/README[40-46]

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

---

2. Runner pull breaks arm64 🐞 Bug ≡ Correctness

Description

e2e-tests/local-run.sh now pulls the runner image without --platform=linux/amd64, so on arm64
hosts Podman will try to pull an arm64 image/manifest for
quay.io/rhdh-community/rhdh-e2e-runner:main and can fail because the publishing workflow still
builds/pushes linux/amd64 only. This can block local e2e runs on arm64 machines until the image is
actually published as multi-arch.

Code

e2e-tests/local-run.sh[362]

+podman pull "$RUNNER_IMAGE"

Relevance

⭐⭐ Medium

local-run.sh changes often accepted, but no precedent on forcing --platform for podman pull.

PR-#4542

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The script pulls quay.io/.../rhdh-e2e-runner:main without a platform override, while the
build-and-push workflow explicitly builds only linux/amd64, so arm64 hosts may not find a matching
manifest/platform for that tag.

e2e-tests/local-run.sh[4-6]
e2e-tests/local-run.sh[360-363]
.github/workflows/push-e2e-runner.yaml[44-84]

Agent prompt

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

## Issue description
`local-run.sh` no longer forces `linux/amd64` when pulling the runner image. However, the image build workflow currently publishes only `linux/amd64`, so arm64 hosts may fail to pull/run the default runner image tag.

## Issue Context
- `local-run.sh` defaults `RUNNER_IMAGE` to `quay.io/rhdh-community/rhdh-e2e-runner:main`.
- The push workflow sets `PLATFORM=linux/amd64` and builds only that platform.

## Fix Focus Areas
- Make the pull logic resilient: attempt a native pull first, and if it fails due to missing manifest/platform, retry with `--platform=linux/amd64` (or make platform a user-configurable flag with a safe default until multi-arch publishing exists).

### Suggested implementation sketch
```bash
if ! podman pull "$RUNNER_IMAGE"; then
 log::warn "Native-arch pull failed; retrying with --platform=linux/amd64"
 podman pull "$RUNNER_IMAGE" --platform=linux/amd64
fi
```

## Fix Focus Areas (exact locations)
- e2e-tests/local-run.sh[4-6]
- e2e-tests/local-run.sh[360-363]
- .github/workflows/push-e2e-runner.yaml[44-84]

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

---

3. Workflow ignores .yarn changes 🐞 Bug ☼ Reliability

Description

push-e2e-runner.yaml only triggers on .ci/images/Dockerfile and .yarnrc.yml, but the Docker
image build context explicitly includes .yarn/; changes to .yarn/** won’t rebuild/push the
runner image, so Quay can lag behind the repo state for Yarn artifacts included in the image.

Code

.github/workflows/push-e2e-runner.yaml[R4-14]

+  pull_request:
+    paths:
+      - '.ci/images/Dockerfile'
+      - '.yarnrc.yml'
  push:
    branches:
      - main
-      - 'release-1.*'
+      - 'release-*'
    paths:
      - '.ci/images/Dockerfile'
      - '.yarnrc.yml'

Evidence

The workflow path filters do not include .yarn/**, but the Dockerfile copies .yarn into the
image, meaning .yarn changes affect the built artifact without triggering rebuilds.

.github/workflows/push-e2e-runner.yaml[3-15]
.ci/images/Dockerfile[20-23]

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 e2e-runner image build workflow triggers only when `.ci/images/Dockerfile` or `.yarnrc.yml` changes. However, the Dockerfile copies the `.yarn/` directory into the image, so changes under `.yarn/**` can change the produced image but won’t trigger a rebuild/push.

### Issue Context
This can lead to Quay publishing an image that doesn’t reflect the repo’s current `.yarn/` artifacts.

### Fix Focus Areas
- .github/workflows/push-e2e-runner.yaml[3-15]
- .ci/images/Dockerfile[20-23]

### Suggested fix
Add `.yarn/**` (or narrower `.yarn/releases/**` and `.yarn/patches/**`) to the `paths:` filters under both `pull_request` and `push` triggers.

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

---

4. Apt lists not cleaned ✓ Resolved 🐞 Bug ➹ Performance

Description

The skopeo/podman install layer runs apt-get update/apt-get install without removing
/var/lib/apt/lists/*, leaving package indexes in the final image layer and increasing image size.
Other install layers in this Dockerfile do clean these directories, so this is an unintended
regression.

Code

.ci/images/Dockerfile[R90-92]

+# Install skopeo and podman
RUN apt-get update -y && \
-    apt-get install -y skopeo
+    apt-get install -y --no-install-recommends skopeo podman

Relevance

⭐⭐ Medium

No historical evidence this repo enforces apt lists cleanup; only unrelated Dockerfile feedback
found.

PR-#4575

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The skopeo/podman installation step lacks the cleanup used elsewhere in the Dockerfile, which
leaves apt package list data behind in that layer.

.ci/images/Dockerfile[35-45]
.ci/images/Dockerfile[90-97]

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 `apt-get update/install` layer for `skopeo` and `podman` does not remove `/var/lib/apt/lists/*`, so apt index files remain in the built image.

## Issue Context
Other apt-based install layers in the same Dockerfile clean `apt` lists and temporary directories; this one currently does not.

## Fix Focus Areas
- Add `apt-get clean` and `rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*` in the same `RUN` layer.

## Fix Focus Areas (exact locations)
- .ci/images/Dockerfile[90-93]

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

---

[github-actions]

Image was built and published successfully. It is available at:

• quay.io/rhdh-community/rhdh:pr-5036
• quay.io/rhdh-community/rhdh:pr-5036-27fcb806

[zdrapela]

/agentic_review

[rhdh-qodo-merge]

Code review by qodo was updated up to the latest commit 27fcb80

[github-actions]

The container image build workflow finished with status: cancelled.

[github-actions]

The container image build workflow finished with status: cancelled.

[github-actions]

The container image build workflow finished with status: cancelled.

[github-actions]

Image was built and published successfully. It is available at:

• quay.io/rhdh-community/rhdh:pr-5036
• quay.io/rhdh-community/rhdh:pr-5036-c6f5844c

[zdrapela]

I believe the issues flagged by Qodo and SonarCloud aren't relevant.

• Qodo - works fine in used environments, or already fixed.
• SonarCloud - we need it for executing the E2E tests.

[zdrapela]

/retest

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
1 Accepted issue

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

Image was built and published successfully. It is available at:

• quay.io/rhdh-community/rhdh:pr-5036
• quay.io/rhdh-community/rhdh:pr-5036-524341ef

[zdrapela]

/retest

[zdrapela]

/test e2e-ocp-helm

[rm3l]

/override "SonarCloud Code Analysis"

Changes scoped to the E2E runner. Might make sense to explicitly exclude those E2E-related folders from SonarCloud analysis: https://github.com/redhat-developer/rhdh/blob/main/.sonarcloud.properties

[openshift-ci]

@rm3l: Overrode contexts on behalf of rm3l: SonarCloud Code Analysis

Details

In response to this:

/override "SonarCloud Code Analysis"

Changes scoped to the E2E runner. Might make sense to explicitly exclude those E2E-related folders from SonarCloud analysis: https://github.com/redhat-developer/rhdh/blob/main/.sonarcloud.properties

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.