fix(ci): use single plugin catalog index pin for Helm and Operator

[zdrapela]

Description

The plugin catalog index on :next is currently broken. Cluster Helm e2e was already avoiding that by pinning global.catalogIndex to :1.10 in the showcase values files. Operator e2e did not set CATALOG_INDEX_IMAGE, so it kept the product default (:next) and did not get the same pin.

This PR moves that pin to a single CI override so both install methods stay in sync:

• CATALOG_INDEX_IMAGE_OVERRIDE="quay.io/rhdh/plugin-catalog-index:1.10" in .ci/pipelines/env_variables.sh is the pin.
• CATALOG_INDEX_IMAGE_OVERRIDE="" is the revert; Helm and Operator then use the product :next default again.
• A per-run CATALOG_INDEX_IMAGE (RC/GA/mirror) still wins over the override.
• Both Helm and Operator jobs use the CATALOG_INDEX_IMAGE as the image (including K8s jobs).
• Showcase values no longer hardcode catalogIndex, and Helm paths that were duplicating image --set flags now go through helm::get_image_params so they honor the same variable.

Cluster-free GHA is unchanged: it still resolves :next / :<x.y> as a live index check, not this cluster pin.

This PR incorporates changes proposed in #5122

Which issue(s) does this PR fix

https://redhat.atlassian.net/browse/RHDHBUGS-3658

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 59.96%. Comparing base (9f85882) to head (441ec2b).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5263      +/-   ##
==========================================
- Coverage   63.69%   59.96%   -3.74%     
==========================================
  Files         123      111      -12     
  Lines        2424     2198     -226     
  Branches      576      527      -49     
==========================================
- Hits         1544     1318     -226     
- Misses        878      879       +1     
+ Partials        2        1       -1     

Flag	Coverage Δ
rhdh	59.96% <ø> (-3.74%)	⬇️

Components	Coverage Δ
Backend plugins	∅ <ø> (∅)
Backend app	66.66% <ø> (ø)
Frontend app	58.89% <ø> (ø)
Plugin utils	∅ <ø> (∅)
Dynamic plugins utils	∅ <ø> (∅)

---

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 9f85882...441ec2b. 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.

[zdrapela]

/test ?

[zdrapela]

/test images
/test e2e-ocp-helm
/test e2e-ocp-operator-nightly

[github-actions]

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

• quay.io/rhdh-community/rhdh:pr-5263
• quay.io/rhdh-community/rhdh:pr-5263-b6a23efe

[zdrapela]

/test e2e-aks-operator-nightly
/test e2e-ocp-operator-nightly
/test e2e-ocp-helm-nightly

[github-actions]

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

• quay.io/rhdh-community/rhdh:pr-5263
• quay.io/rhdh-community/rhdh:pr-5263-794c0ff4

[zdrapela]

/test e2e-ocp-operator-nightly

[zdrapela]

/test e2e-aks-operator-nightly

[zdrapela]

/test e2e-gke-operator-nightly

[rhdh-qodo-merge]

PR Summary by Qodo

CI: centralize plugin catalog index pin via CATALOG_INDEX_IMAGE_OVERRIDE

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

AI Description

• Pin plugin catalog index in CI to avoid broken :next across cluster e2e jobs.
• Route Helm cluster installs through helm::get_image_params for consistent image/catalog overrides.
• Remove duplicated catalogIndex pins from showcase values and improve CI logging/help text.

Diagram

graph TD
  A[".ci/pipelines/env_variables.sh"] --> B{"Resolve CATALOG_INDEX_IMAGE"} --> C["CATALOG_INDEX_IMAGE (resolved)"] --> D["helm::get_image_params()"] --> E["Cluster Helm deploy scripts"] --> F["Helm chart install"]
  C --> G["openshift-ci-tests.sh (logs)"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Keep pins in Helm values + add Operator env injection

• ➕ No change to shared env variable resolution logic
• ➕ Pins are local to each install method (less risk of unexpected cross-job coupling)
• ➖ Duplication (values + operator) is easy to drift out of sync again
• ➖ Harder to audit/override consistently across job variants

2. Pin via chart/operator defaults (product-level)

• ➕ Single authoritative default for all consumers (CI + users)
• ➖ Violates stated goal (CI-only workaround) and could impact real users
• ➖ Creates release-management burden for what is a temporary upstream issue

3. Preflight validate :next index and fail fast instead of pinning

• ➕ Avoids hiding issues by pinning; surfaces breakages immediately
• ➕ Keeps CI using intended :next path
• ➖ Does not unblock cluster e2e when :next is broken
• ➖ Adds extra network dependency and potential flakiness to CI

Recommendation: The PR’s approach (CI-only centralized override with clear precedence and fallback) is the best fit for a temporary :next outage. It removes duplicated pins, keeps Helm and Operator paths aligned via a single variable, and preserves the ability for per-run overrides (RC/GA/mirror) to take precedence.

Files changed (10) +27 / -40

Tests (1) +1 / -1

runtime-config.tsAlign Helm set-args comment with chart default behavior +1/-1

Align Helm set-args comment with chart default behavior

• Updates an in-code comment to no longer claim the chart default catalog index is 1.10, keeping documentation consistent now that the pin is CI-driven rather than values-driven.

e2e-tests/playwright/utils/runtime-config.ts

Documentation (1) +1 / -1

trigger-nightly-job.shUpdate --catalog-index-image help text to reflect override behavior +1/-1

Update --catalog-index-image help text to reflect override behavior

• Simplifies the CLI help description for --catalog-index-image by removing the now-misleading default description, aligning docs with the new precedence-based resolution.

.ci/pipelines/trigger-nightly-job.sh

Other (8) +25 / -38

aks-helm-deployment.shUse helm::get_image_params for AKS Helm installs +4/-6

Use helm::get_image_params for AKS Helm installs

• Replaces explicit --set flags for upstream.backstage.image.{registry,repository,tag} with the shared helm::get_image_params output. Adds a shellcheck disable for command substitution to match the new pattern.

.ci/pipelines/cluster/aks/aks-helm-deployment.sh

eks-helm-deployment.shUse helm::get_image_params for EKS Helm installs +4/-6

Use helm::get_image_params for EKS Helm installs

• Updates the Helm upgrade/install invocation to rely on helm::get_image_params instead of duplicating image --set flags. Adds a shellcheck disable for the command substitution usage.

.ci/pipelines/cluster/eks/eks-helm-deployment.sh

gke-helm-deployment.shUse helm::get_image_params for GKE Helm installs +4/-6

Use helm::get_image_params for GKE Helm installs

• Switches GKE Helm deployment scripts to use helm::get_image_params while retaining GKE-specific ingress annotation settings. Adds a shellcheck disable to accommodate $(...) in the Helm command.

.ci/pipelines/cluster/gke/gke-helm-deployment.sh

env_variables.shIntroduce CATALOG_INDEX_IMAGE_OVERRIDE pin with RELEASE_VERSION fallback +8/-5

Introduce CATALOG_INDEX_IMAGE_OVERRIDE pin with RELEASE_VERSION fallback

• Defines a temporary CI pin via CATALOG_INDEX_IMAGE_OVERRIDE (defaulting to quay.io/rhdh/plugin-catalog-index:1.10). Updates catalog index resolution precedence to: explicit CATALOG_INDEX_IMAGE → override → quay.io/rhdh/plugin-catalog-index:${RELEASE_VERSION}, and clarifies derived Helm parameter behavior.

.ci/pipelines/env_variables.sh

openshift-ci-tests.shLog resolved CATALOG_INDEX_IMAGE in CI jobs +3/-0

Log resolved CATALOG_INDEX_IMAGE in CI jobs

• Adds an informational log line emitting the chosen catalog index image when CATALOG_INDEX_IMAGE is set, making it easier to verify cluster jobs are using the intended pin/override.

.ci/pipelines/openshift-ci-tests.sh

utils.shUse helm::get_image_params for upgrade deployments +2/-3

Use helm::get_image_params for upgrade deployments

• Replaces duplicated image-related Helm --set flags with helm::get_image_params in the upgrade deployment path, ensuring consistent application of image/catalog env vars.

.ci/pipelines/utils.sh

values_showcase-rbac.yamlRemove hardcoded global.catalogIndex image pin from RBAC showcase values +0/-6

Remove hardcoded global.catalogIndex image pin from RBAC showcase values

• Deletes the explicit global.catalogIndex.image registry/repository/tag configuration so CI-driven catalog index selection (via env vars) becomes the single source of truth.

.ci/pipelines/value_files/values_showcase-rbac.yaml

values_showcase.yamlRemove hardcoded global.catalogIndex image pin from showcase values +0/-6

Remove hardcoded global.catalogIndex image pin from showcase values

• Removes the explicit global.catalogIndex.image pin to 1.10 from the default showcase values file, avoiding drift between values files and CI overrides.

.ci/pipelines/value_files/values_showcase.yaml

[rhdh-qodo-merge]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 🔗 Cross-repo conflicts (1) 📜 Skill insights (0)

1. Catalog unpin impossible ✓ Resolved 🐞 Bug ≡ Correctness

Description

.ci/pipelines/env_variables.sh overwrites any pre-set CATALOG_INDEX_IMAGE_OVERRIDE and computes
CATALOG_INDEX_IMAGE using :-, so CATALOG_INDEX_IMAGE_OVERRIDE="" (and
CATALOG_INDEX_IMAGE="") cannot disable catalog pinning as documented. This forces both Helm and
Operator paths to always inject a catalog index override, preventing runs from falling back to the
chart/operator product default.

Code

.ci/pipelines/env_variables.sh[R63-64]

+CATALOG_INDEX_IMAGE_OVERRIDE="quay.io/rhdh/plugin-catalog-index:1.10"
+CATALOG_INDEX_IMAGE="${CATALOG_INDEX_IMAGE:-${CATALOG_INDEX_IMAGE_OVERRIDE:-quay.io/rhdh/plugin-catalog-index:${RELEASE_VERSION}}}"

Relevance

●●● Strong

A close accepted precedent specifically removes an unconditional catalog image default to preserve
chart defaults.

PR-#4860

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The override is assigned unconditionally and CATALOG_INDEX_IMAGE uses :-, so empty-string unpin
is impossible; downstream injection is guarded only by -n, meaning the forced non-empty value
always triggers both Helm and Operator overrides.

.ci/pipelines/env_variables.sh[58-72]
.ci/pipelines/openshift-ci-tests.sh[15-27]
.ci/pipelines/install-methods/operator.sh[74-78]
.ci/pipelines/lib/helm.sh[219-237]
e2e-tests/playwright/utils/runtime-config.ts[91-94]

Agent prompt

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

## Issue description
`.ci/pipelines/env_variables.sh` currently hard-sets `CATALOG_INDEX_IMAGE_OVERRIDE` and uses `:-` fallbacks, which treat empty strings as unset. This prevents the intended behavior where setting `CATALOG_INDEX_IMAGE_OVERRIDE=""` (or `CATALOG_INDEX_IMAGE=""`) disables any catalog index injection so Helm/Operator use product defaults.

## Issue Context
- The pipeline supports local overrides via `.ci/pipelines/env_override.local.sh` (sourced before `env_variables.sh`), but the unconditional assignment in `env_variables.sh` clobbers them.
- Both install methods only inject catalog settings when `CATALOG_INDEX_IMAGE` is non-empty; therefore `CATALOG_INDEX_IMAGE` must remain empty for the unpin path.

## Fix Focus Areas
- .ci/pipelines/env_variables.sh[58-72]

### Concrete fix (recommended)
Implement a 3-state override model where **unset** means “use the CI pin”, **empty string** means “disable injection”, and **non-empty** means “use that override”:

```bash
# Default pin only when the variable is UNSET (not when it is set-but-empty)
CATALOG_INDEX_IMAGE_OVERRIDE="${CATALOG_INDEX_IMAGE_OVERRIDE-quay.io/rhdh/plugin-catalog-index:1.10}"

# Per-run CATALOG_INDEX_IMAGE still wins; if it is set to "" it should remain "".
CATALOG_INDEX_IMAGE="${CATALOG_INDEX_IMAGE-${CATALOG_INDEX_IMAGE_OVERRIDE}}"
```

Then ensure derived `CATALOG_INDEX_*` values are only set when `CATALOG_INDEX_IMAGE` is non-empty (current `if [[ -n ... ]]` is fine; optionally `unset` the derived vars in the `else` branch for re-source safety). Update the comments to match the actual precedence and the meaning of an empty string (unpin/disable).

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

---

2. Helm tag type mismatch 🔗 Cross-repo conflict ≡ Correctness

Description

This PR makes Helm-based installs override global.catalogIndex.image.tag via --set using the
pinned value 1.10, which Helm may parse as a number (e.g., 1.1) and/or fail rhdh-chart schema
validation because the chart requires that tag to be a string. This can break CI deployments that
consume redhat-developer/rhdh-chart (AKS/EKS/GKE Helm paths) or cause the wrong catalog index
image to be used.

Code

.ci/pipelines/env_variables.sh[R63-64]

+CATALOG_INDEX_IMAGE_OVERRIDE="quay.io/rhdh/plugin-catalog-index:1.10"
+CATALOG_INDEX_IMAGE="${CATALOG_INDEX_IMAGE:-${CATALOG_INDEX_IMAGE_OVERRIDE:-quay.io/rhdh/plugin-catalog-index:${RELEASE_VERSION}}}"

Relevance

●● Moderate

The type-coercion risk is plausible, but history lacks a close precedent confirming Helm tag
handling here.

PR-#4860

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR now pins catalog index to :1.10 and passes it through helm::get_image_params into Helm
--set overrides. In rhdh-chart, the schema explicitly defines global.catalogIndex.image.tag as
type: string, so a numeric-coerced value (or a rendered 1.1) violates the chart contract and can
break installs or pull the wrong image tag.

.ci/pipelines/env_variables.sh[58-71]
.ci/pipelines/lib/helm.sh[219-235]
.ci/pipelines/cluster/aks/aks-helm-deployment.sh[33-40]
External repo: redhat-developer/rhdh-chart, charts/backstage/values.schema.tmpl.json [107-131]

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 CI pin sets `CATALOG_INDEX_IMAGE_OVERRIDE=...:1.10` and Helm installs now feed the catalog index tag through `--set global.catalogIndex.image.tag=1.10` (via `helm::get_image_params`). Helm `--set` values are YAML-typed, so `1.10` may be treated as a number (becoming `1.1`) and/or rejected by `rhdh-chart`’s JSON schema, which expects `global.catalogIndex.image.tag` to be a **string**.

## Issue Context
`redhat-developer/rhdh-chart` defines `global.catalogIndex.image.tag` as a string field. This PR moves the `1.10` pin out of values YAML (quoted) and into CLI `--set` flags (unquoted), increasing the likelihood of type coercion/validation failure.

## Fix Focus Areas
- .ci/pipelines/lib/helm.sh[219-235]
- e2e-tests/playwright/utils/runtime-config.ts[222-245]
- .ci/pipelines/env_variables.sh[58-71]

### Suggested fix
- Change the catalog index tag override emission to use `--set-string global.catalogIndex.image.tag=...` (and optionally apply `--set-string` to other tag fields for consistency/safety).
- If you want to keep using `--set`, ensure explicit quoting in a way Helm preserves as a string (but `--set-string` is the safest).

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

---

3. Helm params word-split 🐞 Bug ☼ Reliability

Description

The new Helm deployments expand $(helm::get_image_params) unquoted, but helm::get_image_params
returns a whitespace-delimited string built from unquoted env vars, so values containing
whitespace/glob characters will be split/expanded into unintended Helm arguments. This can
deterministically break installs when CI overrides contain such characters and makes failures harder
to diagnose.

Code

.ci/pipelines/cluster/aks/aks-helm-deployment.sh[39]

+    $(helm::get_image_params); then

Relevance

●●● Strong

Accepted shell reliability findings favor fixing unquoted expansions; no matching rejection
precedent appeared.

PR-#2920

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The PR introduces multiple unquoted $(helm::get_image_params) expansions; helm::get_image_params
itself assembles a single unquoted string, which Bash will split on whitespace and expand globs at
the call site.

.ci/pipelines/cluster/aks/aks-helm-deployment.sh[33-40]
.ci/pipelines/lib/helm.sh[219-237]

Agent prompt

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

## Issue description
Several deployment scripts now call Helm with `$(helm::get_image_params)` unquoted. Because `helm::get_image_params` echoes a single whitespace-delimited string, Bash will apply word-splitting and pathname expansion to its output, potentially turning a single intended value into multiple arguments.

## Issue Context
- The PR added these call sites across AKS/EKS/GKE and upgrade paths.
- The current `helm::get_image_params` implementation concatenates arguments into a string (`params+=...`) and `echo`s it.

## Fix Focus Areas
- .ci/pipelines/lib/helm.sh[219-239]
- .ci/pipelines/cluster/aks/aks-helm-deployment.sh[33-40]
- .ci/pipelines/cluster/eks/eks-helm-deployment.sh[32-39]
- .ci/pipelines/cluster/gke/gke-helm-deployment.sh[35-42]
- .ci/pipelines/utils.sh[640-646]

### Concrete fix (recommended)
Refactor `helm::get_image_params` to *populate an array* rather than echoing a string, then expand it as `"${arr[@]}"`.

Example (Bash nameref approach):
```bash
helm::get_image_params() {
 local -n out=$1
 out=(
   --set "upstream.backstage.image.registry=${IMAGE_REGISTRY}"
   --set "upstream.backstage.image.repository=${IMAGE_REPO}"
   --set "upstream.backstage.image.tag=${TAG_NAME}"
 )
 if [[ -n "${CATALOG_INDEX_IMAGE:-}" ]]; then
   out+=(
     --set "global.catalogIndex.image.registry=${CATALOG_INDEX_REGISTRY}"
     --set "global.catalogIndex.image.repository=${CATALOG_INDEX_REPO}"
     --set "global.catalogIndex.image.tag=${CATALOG_INDEX_TAG}"
   )
 fi
}
```
Call site:
```bash
local -a image_params
helm::get_image_params image_params
helm upgrade ... "${image_params[@]}" ...
```
This removes word-splitting/globbing hazards and eliminates the need for `SC2046` suppressions.

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

---

Context

✅ Compliance rules (platform): 46 rules

✅ Skills: e2e-verify-fix, e2e-diagnose-and-fix

✅ Cross-repo context — repo relationships

  Explored: repo: redhat-developer/rhdh-operator (sha: a425373c)

  Explored: repo: redhat-developer/rhdh-chart (sha: 0e081376)

Tip of the day

💡 Did you know, you can keep summaries lean with Finding overflow, which tucks the rest behind 'View more'

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[rhdh-qodo-merge]

Preparing PR labels...

[zdrapela]

/test e2e-aks-operator-nightly

[github-actions]

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

• quay.io/rhdh-community/rhdh:pr-5263
• quay.io/rhdh-community/rhdh:pr-5263-441ec2b8

[github-actions]

The container image build and publish workflows were skipped (either due to [skip-build] tag or no relevant changes with existing image).

[zdrapela]

/test e2e-ocp-helm

[github-actions]

The container image build and publish workflows were skipped (either due to [skip-build] tag or no relevant changes with existing image).

[openshift-ci]

@zdrapela: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/e2e-ocp-operator-nightly	794c0ff	link	false	/test e2e-ocp-operator-nightly
ci/prow/e2e-aks-operator-nightly	441ec2b	link	false	/test e2e-aks-operator-nightly

Full PR test history. Your PR dashboard.

Details

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. I understand the commands that are listed here.

[zdrapela]

/test e2e-ocp-helm

[github-actions]

The container image build and publish workflows were skipped (either due to [skip-build] tag or no relevant changes with existing image).

[github-actions]

The container image build and publish workflows were skipped (either due to [skip-build] tag or no relevant changes with existing image).

[rostalan]

/lgtm

[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

[github-actions]

The container image build and publish workflows were skipped (either due to [skip-build] tag or no relevant changes with existing image).

[rostalan]

/lgtm