chore: sync codecov components dynamically from overlay support levels

[gustavolira]

Summary

Follow-up to #3425. Makes the Codecov support-level components self-update from rhdh-plugin-export-overlays metadata (spec.support) instead of being hand-maintained, so a plugin promoted from e.g. tech-preview → GA is moved to the right component automatically.

While wiring this up I found that #3425 hard-coded 70 component paths, but this repo only has 24 workspaces — most of those paths (workspaces/3scale/, quay/, acr/, backstage/, …) don't exist here; they're overlay workspace names sourced from backstage/community-plugins and other upstreams, so Codecov tracked nothing for them. The generated block now contains only the workspaces that actually exist in this repo.

Changes

• scripts/generate-codecov-components.sh — rewritten:
  • Reads spec.support from overlay metadata and filters to workspaces present in this repo.
  • Three modes: print (default), --write (rewrites only the component_management block in codecov.yml, preserving flags/coverage/ignore), --check (exits 1 + diff on drift).
  • Deterministic output (no timestamps) so --check is stable; portable across GNU/BSD; shellcheck-clean; back-compatible with the old positional invocation.
• .github/workflows/sync-codecov-components.yml — new:
  • Weekly cron + workflow_dispatch: clones the overlay, runs --write, opens a PR when a support level changed (peter-evans/create-pull-request).
  • pull_request drift check: runs --check on PRs touching codecov.yml and fails if it's out of sync.
  • Reuses the repo's pinned action SHAs, RHDH_BOT_TOKEN, harden-runner, and repo-guard conventions.
• codecov.yml — regenerated to the filtered set (GA 6 / Tech-Preview 4 / Community 3 / Dev-Preview 5 = 18 real paths), dropping paths for non-existent workspaces.
• docs/codecov-support-levels.md — updated for the automated flow and corrected counts/examples.

Verification

• Print / --write / --check all exercised against a real overlay clone; --write is idempotent; negative drift test exits 1 and pinpoints the path.
• codecov.yml remains valid YAML with all existing flags intact.
• shellcheck clean.

Related

• Follow-up to feat: add Codecov components grouped by support level #3425 — RHIDP-13511 / Epic RHIDP-13497 / RHDHPLAN-851

🤖 Generated with Claude Code

[rhdh-qodo-merge]

PR Summary by Qodo

Dynamically sync Codecov components from overlay support levels
✨ Enhancement ⚙️ Configuration changes 📝 Documentation 🕐 20-40 Minutes

Description

• Auto-generate Codecov components from overlay spec.support, filtering to local workspaces.
• Add scheduled + PR-check GitHub Actions workflow to prevent component drift.
• Regenerate codecov.yml block and update docs for new automation.

Diagram

graph TD
  A["Overlay metadata (spec.support)"] --> B["generate-codecov-components.sh"] --> C["codecov.yml (component_management)"]
  D["Sync workflow (schedule/dispatch)"] --> A --> B --> C --> E["create-pull-request"]
  F["Sync workflow (pull_request)"] --> A --> B --> G["--check drift (fail PR)"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Vendor a minimal support-level index into this repo

• ➕ Eliminates cross-repo dependency during CI runs and local generation
• ➕ Makes changes reviewable in the same PR that updates plugins/workspaces
• ➖ Duplicates source-of-truth data and adds another sync burden
• ➖ Still needs a process to keep vendored data aligned with overlay repo

2. Generate Codecov components from repo-local workspace metadata only

• ➕ Avoids cloning the overlay repo in CI and reduces external coupling
• ➕ Keeps all configuration derived from what actually exists in this repo
• ➖ Loses the overlay as the canonical support-level source; support promotions would require manual edits here
• ➖ Harder to keep consistent with downstream/export expectations if overlay remains authoritative

3. Replace workspace-path components with per-package paths for mixed-support workspaces

• ➕ Improves accuracy of component coverage metrics for GA/TP/etc. (reduces skew)
• ➕ Avoids including non-GA package coverage in GA component totals
• ➖ Much larger component lists and higher maintenance/compute overhead
• ➖ Requires stable, predictable per-package path conventions across workspaces

Recommendation: Current approach (overlay-driven generation + scheduled PRs + PR drift check) is the best tradeoff for correctness and maintainability because it keeps support levels sourced from the authoritative overlay metadata while ensuring codecov.yml stays in sync and only includes paths that exist in this repo. The per-package component approach is worth revisiting only if component-level enforcement needs higher precision.

Files changed (4) +346 / -204

Enhancement (1) +158 / -59

generate-codecov-components.shRewrite generator to support --write/--check and filter to local workspaces +158/-59

Rewrite generator to support --write/--check and filter to local workspaces

• Refactors the script to read 'spec.support' values from overlay metadata, group workspaces by support level, and include only workspaces that exist in this repo. Adds stable, deterministic output plus '--write' (in-place replace of 'codecov.yml' block) and '--check' (diff + exit 1 on drift) modes with portable block splicing logic.

scripts/generate-codecov-components.sh

Documentation (1) +64 / -85

codecov-support-levels.mdDocument automated Codecov component sync and updated workspace counts +64/-85

Document automated Codecov component sync and updated workspace counts

• Updates documentation to reflect that the 'component_management' block is generated from overlay metadata, describes the new workflow behaviors (weekly sync PR + PR drift check), and refreshes examples around multi-level workspaces and coverage skew. Adds a changelog entry for the dynamic sync change.

docs/codecov-support-levels.md

Other (2) +124 / -60

sync-codecov-components.ymlAdd workflow to sync and drift-check Codecov components +113/-0

Add workflow to sync and drift-check Codecov components

• Introduces a GitHub Actions workflow that (1) runs weekly/on-demand to regenerate 'codecov.yml' from overlay metadata and open a PR when changes occur, and (2) runs on pull requests touching relevant files to fail on drift using '--check'. Uses pinned action SHAs, hardened runner, sparse checkout of overlay 'workspaces', and bot token for PR creation.

.github/workflows/sync-codecov-components.yml

codecov.ymlRegenerate component_management block to only include existing workspaces +11/-60

Regenerate component_management block to only include existing workspaces

• Replaces the hand-maintained component list with a generated block that documents the new source of truth and automation flow. Drops non-existent workspace paths and updates component counts to reflect only directories present in this repository.

codecov.yml

[rhdh-qodo-merge]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

1. Sync job concurrency key mismatch 🐞 Bug ☼ Reliability

Description

The workflow concurrency group is sync-codecov-components-${{ github.ref }}, but the sync job
always checks out main and writes to the fixed branch automation/sync-codecov-components. A
workflow_dispatch from any non-main ref creates a different concurrency group than the scheduled
run, so both can execute simultaneously and race to update the same PR branch, causing push
conflicts or duplicate PRs.

Code

.github/workflows/sync-codecov-components.yml[R26-28]

+concurrency:
+  group: sync-codecov-components-${{ github.ref }}
+  cancel-in-progress: true

Relevance

⭐⭐ Medium

No prior feedback on concurrency-key/branch mismatch; repo often uses github.ref-based concurrency
(e.g., #2202/#2389).

PR-#2202
PR-#2389

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The concurrency group uses github.ref (line 27), which varies per triggering ref. The sync job
(lines 63–113) always checks out main (line 77) and targets the fixed branch
automation/sync-codecov-components (line 98). Two concurrent runs from different refs (e.g., a
scheduled run on refs/heads/main and a manual dispatch from refs/heads/some-branch) would each
have a distinct concurrency key and would both proceed to write to the same branch, causing a race.

.github/workflows/sync-codecov-components.yml[26-28]
.github/workflows/sync-codecov-components.yml[63-99]

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 workflow-level `concurrency.group` is `sync-codecov-components-${{ github.ref }}`. Because the sync job always targets `main` and writes to the fixed branch `automation/sync-codecov-components`, two runs triggered from different refs (e.g., a scheduled run on `main` and a manual `workflow_dispatch` from another branch) will have different concurrency keys and can execute simultaneously, racing to push to the same branch.

## Issue Context
The `check` job (PR drift check) is ref-specific and benefits from per-ref concurrency. The `sync` job, however, always operates on `main` and a fixed target branch, so it needs a ref-independent concurrency key.

## Fix Focus Areas
- `.github/workflows/sync-codecov-components.yml[26-28]` — change the workflow-level concurrency group, or move the concurrency key to the `sync` job level using a fixed string such as `sync-codecov-components-sync` so only one sync run can proceed at a time regardless of the triggering ref.

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

---

[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