E2E Deploy Rhdh

Deploy RHDH

Deploy Red Hat Developer Hub to a cluster for E2E test execution using the existing local-run.sh workflow.

When to Use

Use this skill when you need a running RHDH instance to reproduce and fix a test failure.

Prerequisites

Before running the deployment, verify these tools are installed:

# Required tools (local-run.sh checks these automatically)
podman --version        # Container runtime
oc version              # OpenShift CLI
kubectl version --client # Kubernetes CLI
vault --version         # HashiCorp Vault (for secrets)
jq --version            # JSON processor
curl --version          # HTTP client
rsync --version         # File sync
bc --version            # Calculator (for resource checks)

Podman Machine Requirements

The podman machine must be running with adequate resources:

podman machine inspect | jq '.Resources'
# Requires: >= 8GB RAM, >= 4 CPUs

If resources are insufficient:

podman machine stop
podman machine set --memory 8192 --cpus 4
podman machine start

Deployment Using local-run.sh

The primary deployment method uses e2e-tests/local-run.sh, which handles everything: Vault authentication, cluster service account setup, RHDH deployment, and test execution.

Execution Rules

CRITICAL — deployment is a long-running operation:

1. Never run local-run.sh in the background. Operator installations can take 20-30 minutes. Use the Bash tool with timeout: 600000 (10 minutes) and if it times out, check the container log — do NOT assume failure.
2. Before starting a deployment, check for existing containers:

   podman ps --format "{{.Names}} {{.Status}}" | grep -i rhdh-e2e-runner

   If a deployment container is already running, wait for it to finish instead of starting a new one. Monitor via the container log:

   tail -f e2e-tests/.local-test/container.log

3. Never launch concurrent deployments. Two deployments to the same cluster will race and both fail. If a deployment appears stuck, check the container log and cluster state before deciding it failed.
4. How to detect actual failure vs slow progress: The operator install script outputs detailed debug logs. If the container log shows active progress (timestamps advancing), the deployment is still running. Only consider it failed if:
   • The podman container has exited (podman ps shows no running container)
   • AND the container log shows an error message (e.g., "Failed install RHDH Operator")

CLI Mode (Preferred)

CRITICAL: CLI mode requires all three flags (-j, -r, -t). If -r is omitted, the script falls into interactive mode and will hang in automated contexts.

cd e2e-tests
./local-run.sh -j <full-prow-job-name> -r <image-repo> -t <image-tag> [-s]

Example — OCP job (deploy-only with -s):

cd e2e-tests
./local-run.sh -j periodic-ci-redhat-developer-rhdh-main-e2e-ocp-v4-20-helm-nightly -r rhdh-community/rhdh -t next -s

Example — K8s job (AKS/EKS/GKE) (full execution, no -s):

cd e2e-tests
./local-run.sh -j periodic-ci-redhat-developer-rhdh-main-e2e-eks-helm-nightly -r rhdh-community/rhdh -t next

Example — disconnected OCP nightlies (requires a real OpenShift cluster; connected is fine; no bastion):

cd e2e-tests
# Operator: prepare uses --to-registry OCP_INTERNAL; MIRROR_* bootstrapped in-container
./local-run.sh -j periodic-ci-redhat-developer-rhdh-main-e2e-ocp-disconnected-operator-nightly -r rhdh-community/rhdh -t next -s
# Helm: oc-mirror to the cluster image registry route
./local-run.sh -j periodic-ci-redhat-developer-rhdh-main-e2e-ocp-disconnected-helm-nightly -r rhdh-community/rhdh -t next -s

local-run.sh refuses disconnected jobs unless oc is logged into OpenShift. It passes DISCONNECTED=true and LOCAL_DISCONNECTED=1; the runner writes mirror auth/CA under ${SHARED_DIR}/disconnected-mirror/ (not on the host). Prefer Operator first when validating OCP_INTERNAL, then Helm. Air-gap prepare details live in rhdh-operator — do not paste them here.

Parameters:

• -j / --job: The full Prow CI job name extracted from the Prow URL. The openshift-ci-tests.sh handler uses bash glob patterns (like *ocp*helm*nightly*) to match, so the full name works correctly. Example: periodic-ci-redhat-developer-rhdh-main-e2e-ocp-v4-20-helm-nightly
• -r / --repo: Image repository (required for CLI mode — without it the script enters interactive mode)
• -t / --tag: Image tag (e.g., 1.9, next)
• -s / --skip-tests: Deploy only, skip test execution. OCP jobs only — K8s jobs (AKS, EKS, GKE) do not support this flag and require the full execution pipeline

WARNING: Do NOT use shortened job names like nightly-ocp-helm for -j — these do not match the glob patterns in openshift-ci-tests.sh.

Image Selection

Refer to the e2e-fix-workflow rule for the release branch to image repo/tag mapping table.

Deploy-Only Mode (OCP Jobs Only)

For OCP jobs, deploy without running tests so you can run specific tests manually:

./local-run.sh -j <full-prow-job-name> -r <image-repo> -t <tag> -s

Note: K8s jobs (AKS, EKS, GKE) do not support deploy-only mode. They require the full execution pipeline — run without -s.

What local-run.sh Does

1. Validates prerequisites: Checks all required tools and podman resources
2. Verifies the image: Checks the image exists on quay.io via the Quay API
3. Pulls the runner image: quay.io/rhdh-community/rhdh-e2e-runner:main
4. Authenticates to Vault: OIDC-based login for secrets
5. Sets up cluster access: Creates rhdh-local-tester service account with cluster-admin, generates 48h token
6. Copies the repo: Syncs the local repo to .local-test/rhdh/ (excludes node_modules)
7. Runs a Podman container: Executes container-init.sh inside the runner image, which:
   • Fetches all Vault secrets to /tmp/secrets/
   • Logs into the cluster
   • Sets platform-specific environment variables
   • Runs .ci/pipelines/openshift-ci-tests.sh for deployment