ci: add weekly coverage run against main branch [PLT-103678]

[Sarath1018]

What

Coverage and the SonarCloud scan were gated on github.base_ref == 'main', so they only ran on PRs targeting main — never against main itself. This adds a scheduled weekly coverage run on main.

How

To avoid duplicating the ~50-line integration-test secret mapping across two workflows, the coverage pipeline is extracted into a reusable workflow:

• .github/workflows/coverage.yml (new) — on: workflow_call. Holds the full pipeline: install → typecheck → unit coverage → build → integration .env generation (the secrets block) → integration coverage → SonarCloud scan → summaries. Single source of truth for the env-variable mapping.
• .github/workflows/weekly-coverage.yml (new) — runs Mondays 06:00 UTC (cron: '0 6 * * 1') + manual workflow_dispatch, calling coverage.yml with secrets: inherit. Scheduled runs check out the default branch (main), so SonarCloud performs main-branch analysis.
• .github/workflows/pr-checks.yml — test-and-build now calls coverage.yml via secrets: inherit; test-packages matrix job unchanged.

Notes

• Reusable workflow chosen over a composite action because composite actions can't read secrets.* directly without re-listing every secret as an input — recreating the duplication.
• The Sonar fork guard now also allows the non-PR scheduled event: github.event_name != 'pull_request' || github.event.pull_request.head.repo.fork == false.
• SonarCloud will start showing main-branch quality-gate results where it previously only saw PR analyses.

🤖 Generated with Claude Code

[claude]

The integration-test steps (setup, .env creation, and this run step) have no if: guard in the reusable workflow. The original pr-checks.yml gated every integration-test step with if: github.base_ref == 'main', so integration tests only ran on PRs targeting main. Now that pr-checks.yml calls this reusable workflow unconditionally, integration tests will run on every PR regardless of target branch.

If this is intentional (always run integration tests on all PRs), no change needed — but worth confirming. If you want to preserve the original selective behavior, accept a boolean input and gate the three integration steps on it:

# in workflow_call inputs:
      run_integration:
        description: Whether to run integration tests and SonarCloud
        type: boolean
        required: false
        default: true

# on each integration step:
        if: inputs.run_integration

Then in pr-checks.yml:

    with:
      ref_label: ${{ github.base_ref }}
      run_integration: ${{ github.base_ref == 'main' }}

[claude]

Without a concurrency group, a manual workflow_dispatch trigger can overlap with the scheduled Monday run, wasting API quota and potentially causing credential conflicts. Consider adding before jobs::

Suggested change

	jobs:
	concurrency:
	group: weekly-coverage
	cancel-in-progress: false
	jobs:

cancel-in-progress: false preserves already-running complete coverage passes rather than killing them mid-flight.

[claude]

Review summary

Two findings from this run:

1. Integration tests now run on all PRs (coverage.yml:102).
The original pr-checks.yml gated integration-test steps with if: github.base_ref == 'main'. The reusable coverage.yml has no such guard, so every PR — regardless of target branch — now triggers the full integration suite. If intentional, no change needed; if not, a run_integration: boolean input would restore the selective behavior.

2. No concurrency group in weekly-coverage.yml (weekly-coverage.yml:14).
A manual workflow_dispatch can overlap with the Monday schedule. Adding concurrency: { group: weekly-coverage, cancel-in-progress: false } before jobs: prevents parallel runs without killing an in-flight coverage pass.

🤖 Generated with Claude Code

[claude]

✅ No issues found. Checked for bugs and CLAUDE.md compliance.

[claude]

✅ No issues found. Checked for bugs and CLAUDE.md compliance.

[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