fix(install-script): Wait until Kaniko Job is effectively active before proceeding

[rm3l]

Description

Due to the asynchronous nature of Kubernetes, the job pod might not be available right away after job creation, which caused the subsequent pod name retrieval command to fail in some cases.

Which issue(s) does this PR fix or relate to

• Fixes https://issues.redhat.com/browse/RHDHBUGS-2478

PR acceptance criteria

• Tests
• Documentation

How to test changes / Special notes to the reviewer

Running .rhdh/scripts/install-rhdh-catalog-source.sh --next --install-operator rhdh against a non-OCP cluster should work.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[rhdh-qodo-merge]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶 RHDHBUGS-2478 - Partially compliant Compliant requirements: Fix timing issue where the script queries the Kaniko pod name before any pod exists. Implement polling/wait with a timeout before retrieving the pod name. Add more robust error handling with a clearer failure message and diagnostic output. Non-compliant requirements: Wait specifically for the Kaniko pod to be in a Running state (the PR waits for job .status.active instead). Requires further human verification: Validate in a real non-OCP/GKE environment that invoke_cluster_cli wait job/... --for=jsonpath='{.status.active}'=1 reliably succeeds and prevents the pod lookup failure across timing variations.

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🔒 No security concerns identified

⚡ Recommended focus areas for review Error Output The wait command redirects all output to stderr (>&2) even on success; this may add noise to logs/CI output. Consider redirecting only on failure or using quieter flags if available, while keeping the failure diagnostics (describe job) as-is. if ! invoke_cluster_cli -n "${namespace}" wait "job/${kanikoJobName}" --for=jsonpath='{.status.active}'=1 --timeout=300s >&2; then errorf "unable to get Kaniko job active. Something might be preventing Jobs from being scheduled properly in this cluster" invoke_cluster_cli -n "${namespace}" describe job "${kanikoJobName}" >&2 return 1

📚 Focus areas based on broader codebase context Fragile Wait The new kubectl wait uses --for=jsonpath='{.status.active}'=1, which can be brittle because .status.active may be unset/absent until the controller updates status, causing the wait to fail even though the job will later run. Consider switching to a condition-based wait (or a more tolerant predicate) consistent with other scripts, and keep the diagnostics but avoid hard-failing on a temporarily missing status field. (Ref 1, Ref 2) # RHDHBUGS-2478: the job pod might not be scheduled right away after job creation if ! invoke_cluster_cli -n "${namespace}" wait "job/${kanikoJobName}" --for=jsonpath='{.status.active}'=1 --timeout=300s >&2; then errorf "unable to get Kaniko job active. Something might be preventing Jobs from being scheduled properly in this cluster" invoke_cluster_cli -n "${namespace}" describe job "${kanikoJobName}" >&2 return 1 fi Reference reasoning: Existing repo scripts use kubectl wait --for=condition=... (e.g., waiting for CRDs Established) rather than jsonpath comparisons on status fields, which tends to be more resilient to transient/absent fields during asynchronous reconciliation. Aligning with that pattern reduces flakiness from missing .status.* values.

📄 References redhat-developer/rhdh-operator/config/profile/rhdh/plugin-infra/plugin-infra.sh [50-75] redhat-developer/rhdh-operator/config/profile/rhdh/plugin-infra/plugin-infra.sh [1-49] redhat-developer/rhdh-operator/config/profile/rhdh/plugin-infra/gitops-secret-setup.sh [199-222] redhat-developer/rhdh-operator/config/profile/rhdh/plugin-infra/gitops-secret-setup.sh [64-87] redhat-developer/rhdh-operator/config/profile/rhdh/plugin-infra/gitops-secret-setup.sh [133-182] redhat-developer/rhdh-operator/config/profile/rhdh/plugin-infra/gitops-secret-setup.sh [87-130] redhat-developer/rhdh-chart/hack/orchestrator-templates-setup.sh [57-100] redhat-developer/rhdh-chart/hack/orchestrator-templates-setup.sh [1-57]

[rhdh-qodo-merge]

PR Type

Bug fix

---

Description

• Add wait condition for Kaniko Job to be active before pod retrieval

• Set parallelism and completions to 1 in Job spec for consistency

• Improve error handling with descriptive message and job details output

---

File Walkthrough

Relevant files

Bug fix

install-rhdh-catalog-source.sh Add job active status wait and improve error handling        .rhdh/scripts/install-rhdh-catalog-source.sh Added parallelism: 1 and completions: 1 fields to Kaniko Job spec Implemented wait condition using kubectl wait to ensure job reaches active status before pod retrieval Added error handling with descriptive message and job description output on timeout Prevents race condition where pod might not be scheduled immediately after job creation +8/-0

---

[rhdh-qodo-merge]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Wait for pod readiness Replace the wait on the job's status with a wait for the pod's Ready condition using wait --for=condition=ready pod -l job-name=.... This is more robust and ensures the pod is running before proceeding. .rhdh/scripts/install-rhdh-catalog-source.sh [580] -if ! invoke_cluster_cli -n "${namespace}" wait "job/${kanikoJobName}" --for=jsonpath='{.status.active}'=1 --timeout=300s >&2; then +if ! invoke_cluster_cli -n "${namespace}" wait --for=condition=ready pod -l job-name="${kanikoJobName}" --timeout=300s >&2; then Apply / Chat Suggestion importance[1-10]: 8 __ Why: The suggestion correctly identifies a potential race condition in the wait command and proposes a more robust solution by waiting for the pod's Ready condition directly, which is the ultimate goal before proceeding with subsequent commands.	Medium
More

[subhashkhileri]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: subhashkhileri
Once this PR has been reviewed and has the lgtm label, please assign nickboldt for approval. For more information see the Code Review Process.

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

Details

Needs approval from an approver in each of these files:

• OWNERS

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