[release-1.10] ci: re-add --upgrade option to ct args

[rm3l]

Followup to #482
To test in-place upgrades.

[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

✅ Cross-repo context

  Not relevant to this PR: redhat-developer/rhdh

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

  Not relevant to this PR: redhat-developer/rhdh-must-gather

1. Upgrade enabled for all runs 🐞 Bug ➹ Performance

Description

The composite action now always adds --upgrade to ct install, so every workflow using it
(including the nightly all-charts job) will run chart-testing in upgrade mode. This changes the
behavior/scope of nightly CI compared to before and increases chart-testing work for runs that may
not intend to exercise upgrade behavior.

Code

.github/actions/test-charts/action.yml[R200-203]

        CT_ARGS=(
          --config ct-install.yaml
+          --upgrade
          --target-branch "$INPUT_TARGET_BRANCH"

Relevance

⭐ Low

Nightly CI is intentionally used for broader coverage; recent CI changes explicitly restore/expand
nightly testing scope (PRs #297, #480).

PR-#297
PR-#480

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The composite action unconditionally includes --upgrade in CT_ARGS, and the nightly workflow
uses this action for all charts; therefore, scheduled nightly CI will now also run chart-testing
with upgrade mode enabled.

.github/actions/test-charts/action.yml[181-205]
.github/workflows/nightly.yaml[50-56]

Agent prompt

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

### Issue description
`--upgrade` is currently always passed to `ct install` in the composite action, which affects all callers (including scheduled nightly runs). If upgrade-mode testing is only desired for certain workflows (e.g., PR in-place upgrade validation), it should be opt-in or conditional.

### Issue Context
The nightly workflow invokes the composite action with `all_charts: 'true'` and sets `target_branch` to the checked-out branch, so it will now also run with `--upgrade` enabled.

### Fix Focus Areas
- .github/actions/test-charts/action.yml[181-215]
- .github/workflows/nightly.yaml[50-56]

### Suggested implementation approach
- Add a new composite action input like `upgrade` (default: `'false'`).
- Append `--upgrade` to `CT_ARGS` only when `inputs.upgrade == 'true'` (or only for PR workflows).
- Update workflows that actually need upgrade testing to pass `upgrade: 'true'` explicitly.

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

---

[rhdh-qodo-merge]

PR Summary by Qodo

CI: re-add ct --upgrade flag to validate in-place chart upgrades

🧪 Tests ⚙️ Configuration changes 🕐 Less than 5 minutes

AI Description

• Re-add the --upgrade flag to chart-testing (ct) invocation in CI.
• Ensure chart tests exercise in-place upgrade paths, not just fresh installs.

Diagram

graph TD
  W["GitHub workflow"] --> A["test-charts action"] --> F["ct args: --upgrade"] --> CT["chart-testing (ct)"] --> HU["Helm upgrade test"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Make `--upgrade` an action input toggle

• ➕ Allows running install-only tests for faster PR feedback when desired
• ➕ Lets release branches enforce upgrade coverage while feature branches stay faster
• ➖ Adds an input surface area to document and maintain
• ➖ May reduce upgrade coverage if teams forget to enable it

2. Split CI into separate install + upgrade jobs

• ➕ Clearer signal: failures are attributable to install vs upgrade
• ➕ Can run upgrade job conditionally (nightly/release branches) without slowing every PR
• ➖ More workflow complexity and CI minutes
• ➖ Requires coordinating job conditions/branch rules

Recommendation: If the goal is to ensure upgrade coverage on every PR for this release branch, the current always-on --upgrade change is appropriate and simplest. If CI time becomes an issue, consider promoting this to a configurable input or a separate upgrade-focused job.

Files changed (1) +1 / -0

Other (1) +1 / -0

action.ymlAdd '--upgrade' to ct argument list +1/-0

Add '--upgrade' to ct argument list

• Adds the '--upgrade' flag back into the CT_ARGS array so chart-testing runs upgrade checks during CI.

.github/actions/test-charts/action.yml