ci: post per-assembly coverage as sticky pr comment #33

2026-05-07T11:02:03-04:00

jasoncouture commented

2026-05-07 11:02:03 -04:00

(Migrated from github.com)

Summary

PR-side coverage feedback. Uses the run-tests composite action introduced in PR #32 to compute coverage identically to main, then posts the per-assembly markdown summary as an upserted sticky comment under header coverage.

What's in here

.github/workflows/pr-coverage.yml:

Trigger: pull_request against main or release/**.
Permissions: contents: read, pull-requests: write (required for upsert).
Concurrency: per-PR group with cancel-in-progress: true — only the latest commit's coverage is interesting.
Steps: actions/checkout@v4 (fetch-depth 0 for NBGV) → actions/setup-dotnet@v4 (10.0.x) → local ./.github/actions/run-tests → marocchino/sticky-pull-request-comment@v2 posting code-coverage-results.md under header coverage.

Why marocchino/sticky-pull-request-comment

It's the canonical "upsert one comment with this header" action, with explicit support for the marker-comment pattern that survives across pushes. Per repo policy, pinned to floating major (@v2).

Failure behavior

Tests failing aborts the run-tests action before the markdown is generated; no comment is posted on a failing build. The PR check reports red regardless. This matches the agreed-upon "just fail" behavior for PR 2.

Test plan

Husky docs-api-up-to-date pre-push check passed.
Real verification needs the workflow to run on a PR — that happens after merge into the chain. Will materialize on PRs that come after this one targeting main.

Stacking note

Targets ci/run-tests-action (PR #32). Will retarget main automatically when #32 merges.

🤖 Generated with Claude Code

## Summary PR-side coverage feedback. Uses the `run-tests` composite action introduced in PR #32 to compute coverage identically to main, then posts the per-assembly markdown summary as an upserted sticky comment under header `coverage`. ## What's in here `.github/workflows/pr-coverage.yml`: - Trigger: `pull_request` against `main` or `release/**`. - Permissions: `contents: read`, `pull-requests: write` (required for upsert). - Concurrency: per-PR group with `cancel-in-progress: true` — only the latest commit's coverage is interesting. - Steps: `actions/checkout@v4` (fetch-depth 0 for NBGV) → `actions/setup-dotnet@v4` (10.0.x) → local `./.github/actions/run-tests` → `marocchino/sticky-pull-request-comment@v2` posting `code-coverage-results.md` under header `coverage`. ## Why marocchino/sticky-pull-request-comment It's the canonical "upsert one comment with this header" action, with explicit support for the marker-comment pattern that survives across pushes. Per repo policy, pinned to floating major (`@v2`). ## Failure behavior Tests failing aborts the `run-tests` action before the markdown is generated; no comment is posted on a failing build. The PR check reports red regardless. This matches the agreed-upon "just fail" behavior for PR 2. ## Test plan - [x] Husky `docs-api-up-to-date` pre-push check passed. - [ ] Real verification needs the workflow to run on a PR — that happens after merge into the chain. Will materialize on PRs that come after this one targeting `main`. ## Stacking note Targets `ci/run-tests-action` (PR #32). Will retarget `main` automatically when #32 merges. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

CLAassistant commented

2026-05-07 11:02:10 -04:00

(Migrated from github.com)

All committers have signed the CLA.

[![CLA assistant check](https://cla-assistant.io/pull/badge/signed)](https://cla-assistant.io/jasoncouture/llama-shears?pullRequest=33) <br/>All committers have signed the CLA.

copilot-pull-request-reviewer[bot] (Migrated from github.com) reviewed

2026-05-07 11:06:37 -04:00

copilot-pull-request-reviewer[bot] (Migrated from github.com) left a comment

Pull request overview

Adds a PR-triggered GitHub Actions workflow that runs the repo’s standardized test+coverage pipeline and posts the per-assembly coverage markdown as an upserted (“sticky”) PR comment.

Changes:

Introduces pr-coverage workflow triggered on pull_request to main / release/**.
Runs ./.github/actions/run-tests to produce code-coverage-results.md.
Posts/updates a sticky PR comment (header coverage) from the generated markdown.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

## Pull request overview Adds a PR-triggered GitHub Actions workflow that runs the repo’s standardized test+coverage pipeline and posts the per-assembly coverage markdown as an upserted (“sticky”) PR comment. **Changes:** - Introduces `pr-coverage` workflow triggered on `pull_request` to `main` / `release/**`. - Runs `./.github/actions/run-tests` to produce `code-coverage-results.md`. - Posts/updates a sticky PR comment (header `coverage`) from the generated markdown. --- 💡 <a href="/jasoncouture/llama-shears/new/ci/run-tests-action?filename=.github/instructions/*.instructions.md" class="Link--inTextBlock" target="_blank" rel="noopener noreferrer">Add Copilot custom instructions</a> for smarter, more guided reviews. <a href="https://docs.github.com/en/copilot/customizing-copilot/adding-repository-custom-instructions-for-github-copilot" class="Link--inTextBlock" target="_blank" rel="noopener noreferrer">Learn how to get started</a>.

.github/workflows/pr-coverage.yml

					
				@ -0,0 +9,4 @@

				permissions:

				  contents: read

				  pull-requests: write

The workflow grants pull-requests: write for the whole job, and the job executes PR code during dotnet test. That exposes a write-capable token to untrusted code (e.g., it can be extracted from checkout git credentials) and increases blast radius if a test is compromised. Consider splitting into two jobs (test/coverage with read-only permissions + artifact, then a second job with pull-requests: write that downloads code-coverage-results.md and posts the sticky comment), or otherwise scope write permissions to the minimal job that needs them.

The workflow grants `pull-requests: write` for the whole job, and the job executes PR code during `dotnet test`. That exposes a write-capable token to untrusted code (e.g., it can be extracted from checkout git credentials) and increases blast radius if a test is compromised. Consider splitting into two jobs (test/coverage with read-only permissions + artifact, then a second job with `pull-requests: write` that downloads `code-coverage-results.md` and posts the sticky comment), or otherwise scope write permissions to the minimal job that needs them.

.github/workflows/pr-coverage.yml

					
				@ -0,0 +33,4 @@

				        uses: marocchino/sticky-pull-request-comment@v2

				        with:

				          path: code-coverage-results.md

				          header: coverage

The comment-posting step may fail on PRs where GITHUB_TOKEN cannot be granted write permissions (commonly PRs from forks), which would turn the whole check red even if tests/coverage succeeded. Consider guarding this step to only run for same-repo PRs (or otherwise handling the no-write-token case gracefully) so forked PRs still get a useful green signal from the coverage job.

The comment-posting step may fail on PRs where `GITHUB_TOKEN` cannot be granted write permissions (commonly PRs from forks), which would turn the whole check red even if tests/coverage succeeded. Consider guarding this step to only run for same-repo PRs (or otherwise handling the no-write-token case gracefully) so forked PRs still get a useful green signal from the coverage job.

Sign in to join this conversation.

No reviewers