fix: osd not inherititng new OSD version

[Omar-AlJaljuli]

Description

Please explain the changes you made here.

Which issue(s) does this PR fix

• Fixes RHDHBUGS-3502

PR acceptance criteria

Please make sure that the following steps are complete:

• GitHub Actions are completed and successful
• Unit Tests are updated and passing
• E2E Tests are updated and passing
• Documentation is updated if necessary (requirement for new features)
• Add a screenshot if the change is UX/UI related

How to test changes / Special notes to the reviewer

[Omar-AlJaljuli]

/test

[Omar-AlJaljuli]

/test e2e-osd-gcp-helm-nightly
/test e2e-osd-gcp-operator-nightly

[rhdh-qodo-merge]

PR Summary by Qodo

Pin OSD GCP cluster creation to OSD version 4.20.17

🐞 Bug fix ⚙️ Configuration changes 🕐 Less than 10 minutes

AI Description

• Prevent CI OSD cluster creation from using a stale inherited OSD_VERSION.
• Pin OSD GCP cluster creation to version 4.20.17 for consistent provisioning.

Diagram

graph TD
  A(["CI pipeline: create OSD"]) --> B["create-osd.sh"] -->|"--version 4.20.17"| C(["ocm CLI"]) --> D{{"OCM/OSD API"}} --> E(["GCP OSD cluster"])
  subgraph Legend
    direction LR
    _job(["Job/step"]) ~~~ _file["Script file"] ~~~ _ext{{"External service"}}
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Keep env override but guard against stale/empty values

• ➕ Allows controlled overrides for testing newer/older OSD versions without code changes
• ➕ Avoids hard-coding version in the script
• ➖ Still vulnerable if upstream CI exports an incorrect OSD_VERSION unless additional validation is added
• ➖ More logic and decision points in a critical provisioning path

2. Centralize OSD version in CI config (single source of truth)

• ➕ Version changes become a config change rather than a script change
• ➕ Reduces drift across multiple cluster-creation scripts/pipelines
• ➖ Requires additional wiring/ownership of where the canonical version lives
• ➖ May be overkill if this is the only consumer

Recommendation: If the core issue is upstream CI injecting an older OSD_VERSION, pinning the version in this script is a pragmatic fix. Longer-term, consider centralizing the OSD version in CI configuration (or adding validation) to avoid future drift while preserving intentional override capability.

Files changed (1) +1 / -1

Bug fix (1) +1 / -1

create-osd.shStop inheriting OSD_VERSION and pin to 4.20.17 +1/-1

Stop inheriting OSD_VERSION and pin to 4.20.17

• Changes OSD version selection from an environment-inheriting default to a fixed value. This prevents upstream CI environment variables from forcing an unintended (older) OSD version during GCP cluster provisioning.

.ci/pipelines/cluster/osd-gcp/create-osd.sh

[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]

Code Review by Qodo

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

Context used

⚠️ Tickets: not configured — ticket URL found in PR but could not be fetched — check ticket provider credentials

✅ Compliance rules (platform): 46 rules

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

✅ Cross-repo context

  Not relevant to this PR: redhat-developer/rhdh-plugins

  Not relevant to this PR: redhat-developer/rhdh-chart

  Not relevant to this PR: redhat-developer/rhdh-operator

  Not relevant to this PR: redhat-developer/rhdh-local

1. OSD_VERSION override removed 🐞 Bug ≡ Correctness

Description

create-osd.sh now assigns OSD_VERSION unconditionally, so any caller/CI-provided OSD_VERSION
is ignored and the script always creates clusters with version 4.20.17. This can cause OSD-GCP jobs
to run against an unintended OpenShift version and makes version bumps harder to roll out safely.

Code

.ci/pipelines/cluster/osd-gcp/create-osd.sh[11]

+OSD_VERSION="4.20.17"

Relevance

⭐⭐⭐ High

Repo precedent keeps CI version vars overrideable via env-defaulting; hard-pin would break expected
override behavior.

PR-#4531
PR-#4860

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The script now hard-sets OSD_VERSION while other credentials use env-var defaulting, and that
value is then used as the --version argument to ocm create cluster, so callers can no longer
influence the target OSD version via OSD_VERSION.

.ci/pipelines/cluster/osd-gcp/create-osd.sh[8-12]
.ci/pipelines/cluster/osd-gcp/create-osd.sh[33-36]

Agent prompt

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

### Issue description
`OSD_VERSION` is currently hard-coded (`OSD_VERSION="4.20.17"`), which overwrites any `OSD_VERSION` set by the environment. This removes the previously supported mechanism to select the target OSD version per run.

### Issue Context
Other inputs in the same script (e.g., `CLIENT_ID`, `CLIENT_SECRET`, `SERVICE_ACCOUNT_FILE`) are explicitly designed to be overrideable via environment variables using bash defaulting (`${VAR:-...}`). `OSD_VERSION` is later passed directly into `ocm create cluster --version "$OSD_VERSION"`, so the unconditional assignment forces all clusters to be created with the pinned version.

### Fix Focus Areas
- .ci/pipelines/cluster/osd-gcp/create-osd.sh[8-12]
- .ci/pipelines/cluster/osd-gcp/create-osd.sh[33-36]

### Suggested fix
- Change back to defaulting semantics, e.g.:
 - `OSD_VERSION="${OSD_VERSION:-4.20.17}"`
- (Optional, if desired by the original bug intent) consider using the already-commented dynamic approach with a safe fallback, e.g. compute latest from `ocm list versions` when `OSD_VERSION` is unset, but keep explicit env override support.

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

---

[openshift-ci]

@Omar-AlJaljuli: 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-osd-gcp-operator-nightly	ad2a4a0	link	false	/test e2e-osd-gcp-operator-nightly
ci/prow/e2e-osd-gcp-helm-nightly	ad2a4a0	link	false	/test e2e-osd-gcp-helm-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.