ci(nightly): skip developer-lightspeed on main and release-1.10

[rm3l]

Description

Lightspeed is fully integrated with the base deployment on main and release-1.10, so the separate developer-lightspeed compose overlay is redundant for those branches.

This adds a matrix exclusion for main (matching the existing one for release-1.10) and updates the TODO comment to reflect when the config and exclude rules can be fully removed (once all supported branches include Lightspeed in the base deployment).

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

https://github.com/redhat-developer/rhdh-local/actions/runs/27821414144/job/82335212290

PR acceptance criteria

• Tests updated and passing
• Documentation updated
• Built-in TechDocs updated if needed. Note that TechDocs changes may need to be reviewed by a Product Manager and/or Architect to ensure content accuracy, clarity, and alignment with user needs.

How to test changes / Special notes to the reviewer

[rhdh-qodo-merge]

PR Summary by Qodo

CI nightly: skip developer-lightspeed on main and release-1.10
⚙️ Configuration changes 🕐 Less than 10 minutes

Description

• Exclude the developer-lightspeed compose overlay from nightly runs on main.
• Clarify TODO/remove conditions for the overlay once all supported branches ship Lightspeed.
• Document that main and release-1.10 already include Lightspeed in base deployment.

Diagram

graph TD
  A[".github/workflows/nightly.yaml"] --> B(["Nightly job"]) --> C{"Branch selection"}
  C -->|"exclude"| E["main + release-1.10"]
  C -->|"include"| F["older releases"] --> D["developer-lightspeed overlay"]

  subgraph Legend
    direction LR
    _file["Workflow file"] ~~~ _job(["Job"]) ~~~ _dec{"Decision"}
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Use job/step `if:` conditions instead of matrix exclusion

• ➕ Avoids duplicating matrix entries for each excluded branch
• ➕ Branch gating is explicit at the job/step level (easy to scan)
• ➖ Harder to keep behavior aligned across multiple composeConfig matrix variants
• ➖ Matrix-driven reporting can become less uniform if jobs are conditionally skipped mid-flight

2. Split nightly workflows per branch family (main vs release branches)

• ➕ No branching logic inside a single workflow; simplest mental model per branch
• ➕ Allows tailored schedules/steps per branch line
• ➖ More workflow files to maintain and keep consistent
• ➖ Higher risk of drift between branch families over time

Recommendation: Keep the current matrix exclusion approach: it matches the existing release-1.10 pattern, is low-risk, and keeps matrix behavior consistent across branches. Consider switching to if: gating only if exclusions continue to grow and become repetitive.

Files changed (1) +8 / -3

Other (1) +8 / -3

nightly.yamlExclude developer-lightspeed matrix entries on main and clarify TODO +8/-3

Exclude developer-lightspeed matrix entries on main and clarify TODO

• Updates the nightly workflow matrix to exclude the 'developer-lightspeed' compose overlay on 'main' (in addition to 'release-1.10'). Refreshes the TODO comment to indicate removal once all supported branches include Lightspeed in the base deployment.

.github/workflows/nightly.yaml

[rm3l]

Only changing the nightly workflow.

[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 (2) 📘 Rule violations (0) 📜 Skill insights (0)

1. Brittle exclude duplication 🐞 Bug ⚙ Maintainability

Description

The workflow duplicates the full developer-lightspeed composeConfig mapping in the matrix axis
and multiple exclude entries; if cliArgs drifts in any one location, GitHub Actions matrix
matching can stop excluding the intended jobs and developer-lightspeed runs can unexpectedly
reappear on skipped branches.

Code

.github/workflows/nightly.yaml[R94-97]

+          - branch: "main"
+            composeConfig:
+              name: "developer-lightspeed"
+              cliArgs: "-f compose.yaml -f developer-lightspeed/compose.yaml"

Relevance

⭐⭐ Medium

They accept workflow dedup/refactors (PR #180), but no history about matrix.exclude object
duplication drift risks.

PR-#180
PR-#229

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The same developer-lightspeed object (name + cliArgs) is defined as a matrix value and then
repeated verbatim in multiple exclusions; this is drift-prone because exclusions depend on matching
these values.

.github/workflows/nightly.yaml[59-71]
.github/workflows/nightly.yaml[88-101]

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 `developer-lightspeed` composeConfig mapping is repeated across the matrix axis and multiple `exclude` rules. Because exclusions rely on value matching, changing the mapping in one place but not the others can silently break the exclusion behavior.

## Issue Context
This PR adds another exclusion (for `main`), increasing the number of duplicated copies of the same mapping.

## Fix Focus Areas
- .github/workflows/nightly.yaml[59-101]

## Proposed fix
- Introduce a YAML anchor for the `developer-lightspeed` composeConfig entry (and optionally other repeated composeConfig objects).
- Reuse the anchored mapping in:
 - `matrix.composeConfig` entry for `developer-lightspeed`
 - `exclude` entries that reference `developer-lightspeed`

Example sketch:
```yaml
composeConfig:
 - &developer_lightspeed
   name: "developer-lightspeed"
   cliArgs: "-f compose.yaml -f developer-lightspeed/compose.yaml"
...
exclude:
 - branch: "main"
   composeConfig: *developer_lightspeed
```

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

---

2. Ambiguous TODO scope 🐞 Bug ⚙ Maintainability

Description

The TODO says to remove “the exclude rules below” once Lightspeed is integrated everywhere, but the
exclude: block also contains unrelated ARM/tool/userConfig exclusions; this wording can mislead
future cleanup into removing broader exclusions than intended.

Code

.github/workflows/nightly.yaml[R68-70]

+          # TODO: Remove this and the exclude rules below once all supported
+          # branches include Lightspeed in the base deployment.
          - name: "developer-lightspeed"

Relevance

⭐⭐⭐ High

Similar TODO/comment clarification was accepted in nightly workflow (PR #229 review).

PR-#229
PR-#180

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The TODO is immediately above the developer-lightspeed composeConfig entry, but the subsequent
exclude: block contains multiple non-Lightspeed exclusions before the Lightspeed-specific ones.

.github/workflows/nightly.yaml[68-71]
.github/workflows/nightly.yaml[72-87]
.github/workflows/nightly.yaml[88-101]

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 TODO comment is placed above the `developer-lightspeed` composeConfig entry but refers to “exclude rules below”, while the `exclude:` list includes several non-Lightspeed exclusions.

## Issue Context
Only the Lightspeed-specific `exclude` entries should be removed when Lightspeed is in the base deployment on all supported branches; the ARM subset exclusions should remain.

## Fix Focus Areas
- .github/workflows/nightly.yaml[68-101]

## Proposed fix
- Reword the TODO to explicitly target the Lightspeed-specific config and exclusions (e.g., “Remove `developer-lightspeed` composeConfig entry and the Lightspeed-specific exclude entries below…”).
- Optionally move the TODO comment to sit directly above the first Lightspeed-specific `exclude` entry to avoid implying all excludes are removable.

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

---