chore: update lightspeed sync action to only sync release branches

[Jdubrick]

Description

Updates the sync action for Lightspeed to only target release branches. For 2.1.0 we will be making breaking changes to the configuration files, and having scheduled sync's will be confusing and breaking.

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

• Fixes #issue_number

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

Limit Lightspeed config sync workflow to release branches

⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Run the Lightspeed config sync job only against a release-branch matrix.
• Ensure checkout, concurrency, and PR targeting are scoped per release branch.
• Prevent scheduled sync PRs from landing on non-release branches during breaking config changes.

Diagram

graph TD
  A["Schedule / Dispatch"] --> B["Sync job (matrix: branch)"] --> C["Checkout (ref=release-*)"] --> D["Run sync script"] --> E["Detect config diffs"] --> F["Create/Update PR (base=target)"] --> G[("GitHub repo")]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Separate workflow per release branch

• ➕ Avoids matrix complexity and per-branch env handling
• ➕ Makes per-branch schedules/permissions easy to customize
• ➖ Duplicates workflow logic and increases maintenance burden
• ➖ Harder to keep behavior consistent across branches

2. Discover release branches dynamically (GitHub API)

• ➕ No manual updates when adding/removing release branches
• ➕ Can enforce naming rules (e.g., release-*) centrally
• ➖ More moving parts (API calls, parsing, auth)
• ➖ Harder to reason about and debug when automation misbehaves

Recommendation: Keep the explicit matrix approach: it’s predictable, easy to audit, and cleanly scopes concurrency/PR targeting per release branch. If the set of supported release branches changes frequently, consider dynamic discovery later, but it’s likely overkill for the current need.

Files changed (1) +16 / -8

Other (1) +16 / -8

sync-lightspeed-configs.yamlScope Lightspeed sync to a release-branch matrix and target PRs accordingly +16/-8

Scope Lightspeed sync to a release-branch matrix and target PRs accordingly

• Introduces a branch matrix (currently release-1.10) and moves concurrency into the job scoped by branch. Checkout now uses the matrix branch ref, and the PR creation/update logic uses a branch-specific head name and explicitly targets the matrix branch as the PR base.

.github/workflows/sync-lightspeed-configs.yaml

[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) 📜 Skill insights (0)

1. Hard-coded release matrix 🐞 Bug ⚙ Maintainability

Description

The workflow only runs for a single hard-coded branch (release-1.10), so other supported or newly
created release branches will not receive Lightspeed sync PRs unless this workflow is manually
updated. This creates a silent coverage gap for scheduled syncs.

Code

.github/workflows/sync-lightspeed-configs.yaml[R13-18]

+    strategy:
+      fail-fast: false
+      matrix:
+        branch:
+          - release-1.10
+

Relevance

⭐⭐⭐ High

PR #180 accepted dynamic release-branch discovery to avoid missing new release branches; hard-coded
matrix opposes that pattern.

PR-#180

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The workflow matrix contains only release-1.10, so it cannot run for any other release branch. The
repo’s nightly workflow demonstrates an existing, accepted approach to dynamically discover release
branches at runtime to prevent missing new releases.

.github/workflows/sync-lightspeed-configs.yaml[13-18]
.github/workflows/nightly.yaml[21-43]
PR-#180

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 sync workflow is pinned to a single branch (`release-1.10`) via the job matrix. This means scheduled sync PRs won’t be opened for other release branches unless someone edits the workflow.

### Issue Context
The repo already contains a pattern for runtime release-branch discovery to avoid this exact maintenance burden.

### Fix Focus Areas
- .github/workflows/sync-lightspeed-configs.yaml[13-18]
- .github/workflows/nightly.yaml[21-43]

### Suggested fix
1. Add a `discover-branches` job (e.g., using `actions/github-script`) that lists repo branches, filters `^release-\d+\.\d+$`, sorts numerically, and selects the desired subset (e.g., latest N).
2. Change the sync job’s matrix to `branch: ${{ fromJson(needs.discover-branches.outputs.branches) }}`.
3. Keep job-level concurrency grouping by `${{ matrix.branch }}` as you already do.

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

---