Wire CodeScene coverage upload on main and prepare the PR gate#72
Conversation
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
Summary
WalkthroughThis PR restructures CI coverage generation and CodeScene upload gating: the CI workflow drops its inline coverage upload in favour of a new dedicated ChangesCoverage workflow restructuring
Pinned shared-action SHA updates
Sequence Diagram(s)sequenceDiagram
participant GitHub as GitHub push to main
participant Workflow as coverage-main.yml
participant Rust as Setup Rust action
participant Coverage as Generate coverage action
participant CodeScene as CodeScene upload
GitHub->>Workflow: trigger on push
Workflow->>Rust: setup toolchain
Workflow->>Coverage: generate lcov.info with ratchet
Coverage-->>Workflow: lcov.info produced
Workflow->>CodeScene: upload if CS_ACCESS_TOKEN set
Possibly related PRs
Suggested reviewers: Poem
Caution Pre-merge checks failedPlease resolve all errors before merging. Addressing warnings is optional.
❌ Failed checks (2 errors, 5 warnings)
✅ Passed checks (13 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
![codescene-access[bot]](https://avatars.githubusercontent.com/in/3755875?s=60&v=4){kind=small}
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Onboard the repository to the CodeScene coverage pipeline. Pull-request runs generate line-level LCOV coverage and advance the ratchet baseline; a new push-to-main workflow uploads that coverage to CodeScene, which accepts uploads only for analysed branches. - Bump every leynos/shared-actions reference (setup-rust, generate-coverage, upload-codescene-coverage, mutation-cargo and dependabot-automerge callers) to 927edd45ae77be4251a8a18ca9eb5613a2e32cbd, which carries the coverage-action fixes and the mode: check support. - Pass use-cargo-nextest: 'false' to preserve the existing plain cargo llvm-cov behaviour, and format: lcov for line-level records. - Enable with-ratchet: 'true' in both the main-push upload workflow (writes the authoritative baseline) and the pull-request coverage job (compares against it). - Check out with fetch-depth: 0 on the pull-request job so a later changed-line gate can reach the merge base. - Defer the mode: check gate: CodeScene project 70676 has no coverage-gates configuration yet, so cs-coverage check fails every run. A comment in ci.yml records the deferral; the step lands in a fast-follow once the gate is enabled CodeScene-side. - Move the workflow contract that guards the guarded upload from ci.yml to coverage-main.yml, and bump the mutation-testing contract pin.
leynos
force-pushed
the
codescene-coverage-gate
branch
from
3d9a9e2 to
b6cb53e
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/ci.yml:
- Around line 18-19: The job-level env in the CI workflow is exposing
CS_ACCESS_TOKEN even though it is not used by the current flow; remove that
secret from the global environment and keep only CODESCENE_CLI_SHA256 there.
Update the Generate coverage / upload-check area in the ci workflow so
CS_ACCESS_TOKEN is added back only when the deferred mode: check step is
introduced, using the existing generate coverage step context to place it where
it is actually consumed.
- Around line 21-23: The ci workflow’s actions/checkout step is using a mutable
tag and still persists credentials. Update the checkout step to use the same
SHA-pinned style as the other actions in this job, and set persist-credentials
to false in the actions/checkout configuration. Keep fetch-depth: 0 if needed,
but ensure checkout is pinned and does not leave repository credentials on the
runner.
In @.github/workflows/coverage-main.yml:
- Around line 12-20: The coverage-main workflow currently has no concurrency
control, so overlapping pushes to main can race while updating the shared
ratchet baseline. Add a concurrency group to this workflow (for example at the
workflow level or within the coverage-upload job) so only one main-branch run
can update the baseline at a time, and ensure the setting targets the
coverage-upload job that writes the shared coverage cache/baseline.
- Line 27: The workflow step using actions/checkout in coverage-main.yml should
be updated to match ci.yml by pinning the checkout action to a full commit SHA
instead of the v4 tag and explicitly disabling credential persistence. Locate
the checkout step in the job definition and change the uses reference to the
pinned actions/checkout entry already used elsewhere, then set
persist-credentials to false so the checkout does not retain GitHub credentials.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 32de8471-ef5c-4b1c-a18b-85e11446ce89
📒 Files selected for processing (6)
.github/workflows/ci.yml.github/workflows/coverage-main.yml.github/workflows/dependabot-automerge.yml.github/workflows/mutation-testing.ymltests/workflow_contracts/mutation_testing_test.pytests/workflows.rs
🔗 Linked repositories identified
CodeRabbit considers these linked repositories for cross-repo context during reviews:
leynos/shared-actions(auto-detected)
| CS_ACCESS_TOKEN: ${{ secrets.CS_ACCESS_TOKEN || '' }} | ||
| CODESCENE_CLI_SHA256: ${{ vars.CODESCENE_CLI_SHA256 || '' }} |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win
Secret sits idle in job env — strip it out until it's actually used.
CS_ACCESS_TOKEN gets injected into the job env at Lines 18-19, but the "Generate coverage" step (Lines 57-63) never references it — the upload/check step is deliberately deferred. Exposing a live secret to every step in the job (including third-party actions like cargo binstall, astral-sh/setup-uv) with no consumer widens the blast radius for zero benefit right now.
Pull the secret env vars back out and reintroduce them alongside the mode: check step when it actually lands.
🔒 Proposed fix
env:
CARGO_TERM_COLOR: always
BUILD_PROFILE: debug
WHITAKER_INSTALLER_VERSION: '0.2.5'
- CS_ACCESS_TOKEN: ${{ secrets.CS_ACCESS_TOKEN || '' }}
- CODESCENE_CLI_SHA256: ${{ vars.CODESCENE_CLI_SHA256 || '' }}Also applies to: 57-63
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/ci.yml around lines 18 - 19, The job-level env in the CI
workflow is exposing CS_ACCESS_TOKEN even though it is not used by the current
flow; remove that secret from the global environment and keep only
CODESCENE_CLI_SHA256 there. Update the Generate coverage / upload-check area in
the ci workflow so CS_ACCESS_TOKEN is added back only when the deferred mode:
check step is introduced, using the existing generate coverage step context to
place it where it is actually consumed.
Source: Linters/SAST tools
| - uses: actions/checkout@v4 | ||
| with: | ||
| fetch-depth: 0 |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Pin actions/checkout and disable credential persistence.
Every other action reference in this job is pinned to a commit SHA (setup-rust@927edd4…, actions/cache@005785…, setup-uv@fac544c…), yet actions/checkout@v4 here is left on a mutable tag, and persist-credentials isn't disabled. Flagged by zizmor as both unpinned-uses (error) and artipacked (warning) — the latter matters more now that fetch-depth: 0 pulls full history into the runner.
🔒 Proposed fix
- - uses: actions/checkout@v4
+ - uses: actions/checkout@<pinned-sha> # vX.Y.Z
with:
fetch-depth: 0
+ persist-credentials: false🧰 Tools
🪛 zizmor (1.26.1)
[warning] 21-23: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 21-21: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/ci.yml around lines 21 - 23, The ci workflow’s
actions/checkout step is using a mutable tag and still persists credentials.
Update the checkout step to use the same SHA-pinned style as the other actions
in this job, and set persist-credentials to false in the actions/checkout
configuration. Keep fetch-depth: 0 if needed, but ensure checkout is pinned and
does not leave repository credentials on the runner.
Source: Linters/SAST tools
| on: | ||
| push: | ||
| branches: [main] | ||
|
|
||
| jobs: | ||
| coverage-upload: | ||
| runs-on: ubuntu-latest | ||
| permissions: | ||
| contents: read |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Add a concurrency group — overlapping pushes to main can race the ratchet baseline.
This workflow triggers on every push to main with no concurrency limit. Rapid successive pushes (e.g. a squash-merge queue) can run two coverage-generation/upload jobs in parallel, both writing to the same ratchet cache/baseline that PR runs compare against — the loser's write is a lost update, corrupting the baseline PR gates rely on.
🔒 Proposed fix
on:
push:
branches: [main]
+concurrency:
+ group: coverage-main-${{ github.ref }}
+ cancel-in-progress: false
+
jobs:
coverage-upload:📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| on: | |
| push: | |
| branches: [main] | |
| jobs: | |
| coverage-upload: | |
| runs-on: ubuntu-latest | |
| permissions: | |
| contents: read | |
| on: | |
| push: | |
| branches: [main] | |
| concurrency: | |
| group: coverage-main-${{ github.ref }} | |
| cancel-in-progress: false | |
| jobs: | |
| coverage-upload: | |
| runs-on: ubuntu-latest | |
| permissions: | |
| contents: read |
🧰 Tools
🪛 zizmor (1.26.1)
[info] 17-17: workflow or action definition without a name (anonymous-definition): this job
(anonymous-definition)
[warning] 12-14: insufficient job-level concurrency limits (concurrency-limits): workflow is missing concurrency setting
(concurrency-limits)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/coverage-main.yml around lines 12 - 20, The coverage-main
workflow currently has no concurrency control, so overlapping pushes to main can
race while updating the shared ratchet baseline. Add a concurrency group to this
workflow (for example at the workflow level or within the coverage-upload job)
so only one main-branch run can update the baseline at a time, and ensure the
setting targets the coverage-upload job that writes the shared coverage
cache/baseline.
Source: Linters/SAST tools
| CS_ACCESS_TOKEN: ${{ secrets.CS_ACCESS_TOKEN || '' }} | ||
| CODESCENE_CLI_SHA256: ${{ vars.CODESCENE_CLI_SHA256 || '' }} | ||
| steps: | ||
| - uses: actions/checkout@v4 |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Pin actions/checkout and disable credential persistence, same as ci.yml.
Same gap as the PR workflow: actions/checkout@v4 is unpinned while every other action in this file is pinned to a SHA, and persist-credentials is left at its default true. Zizmor flags both unpinned-uses and artipacked here.
🔒 Proposed fix
- - uses: actions/checkout@v4
+ - uses: actions/checkout@<pinned-sha> # vX.Y.Z
+ with:
+ persist-credentials: false📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - uses: actions/checkout@v4 | |
| - uses: actions/checkout@<pinned-sha> # vX.Y.Z | |
| with: | |
| persist-credentials: false |
🧰 Tools
🪛 zizmor (1.26.1)
[warning] 27-27: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 27-27: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/coverage-main.yml at line 27, The workflow step using
actions/checkout in coverage-main.yml should be updated to match ci.yml by
pinning the checkout action to a full commit SHA instead of the v4 tag and
explicitly disabling credential persistence. Locate the checkout step in the job
definition and change the uses reference to the pinned actions/checkout entry
already used elsewhere, then set persist-credentials to false so the checkout
does not retain GitHub credentials.
Source: Linters/SAST tools
1 participant
Summary
Onboards this repository to the CodeScene coverage pipeline, following the
estate rollout recipe (proven on mxd#362
and modelled on ddlint#287).
The CodeScene GitHub App posts a
CodeScene Code Coveragecheck on everypull-request head and waits for coverage to be uploaded for that commit;
repositories that never upload leave the check waiting until it times out, and
a timed-out check poisons the whole status rollup — which the shared Dependabot
automerge gate reads in full, so automerge stalls even when every required
check is green. This wiring feeds CodeScene the coverage it expects.
cs-coverage uploadis accepted only for branches CodeScene analyses (main),so the upload lives in a dedicated push-to-main workflow. The pull-request job
generates line-level LCOV coverage and advances the ratchet baseline.
The changed-line PR gate (
mode: check) is deliberately deferred: CodeSceneproject 70676 has no coverage-gates configuration yet, so
cs-coverage checkfails every run with "the received project-config isn't valid. Lacks the gates
configuration." — a CodeScene-side per-project setting, not a CI defect. A
comment in
ci.ymlrecords this; the step lands in a fast-follow once the gateis enabled. Note the CodeScene coverage check is not a repository-required
check — it blocks only through the status rollup, so reviewers will not find it
in the branch ruleset.
Review walkthrough
.github/workflows/ci.yml— bumps the shared-actions pins to
927edd4, checks out withfetch-depth: 0(so a later changed-line gate can reach the merge base),runs
generate-coveragewithformat: lcov,use-cargo-nextest: 'false'(preserves the existing plain
cargo llvm-covbehaviour) andwith-ratchet: 'true', and carries the deferred-gate comment in place of theremoved upload step.
.github/workflows/coverage-main.yml— new; on push to
main, regenerates coverage (ratchet on, writing theauthoritative baseline every PR compares against) and uploads it to CodeScene
under the empty-token guard.
.github/workflows/mutation-testing.ymland
dependabot-automerge.yml— pins bumped to the single repo-wide
927edd4SHA.tests/workflows.rs— relocates the guarded-upload contract from
ci.ymltocoverage-main.yml,where the upload step now lives (job-level token, step-level
ifguard).tests/workflow_contracts/mutation_testing_test.py— bumps the pinned-SHA contract to match the workflow.
Validation
python3 -c "import yaml; ..."parses all four workflow files.make test-workflow-contracts(pytest) passes: 6 passed.make testin thebuild-testjob.CS_ACCESS_TOKENset in both the Actions and Dependabot secret stores; aread-only probe of
GET /v2/projects/70676returns 200 with the estate PAT.The ratchet baseline is written by the first
coverage-main.ymlrun onmainafter merge; the ratchet may report no stored baseline on this PR until then.