From 3c7ddd1a098c8313e26845f45a396ca5e3e4543c Mon Sep 17 00:00:00 2001 From: Svilen Stefanov Date: Wed, 19 Aug 2026 00:50:10 +0200 Subject: [PATCH 1/2] docs: review on every push, now that a push costs a delta The recommended workflow analyzed a pull request once, when it became reviewable, because every run re-derived the whole thing and a run per push was not worth it. A run now continues from the pull request's previous analysis and covers only the commits pushed since, so the reason for leaving synchronize out is gone. It also matters for a second reason: a pushed commit is the only thing that builds that reusable analysis. GitHub gives comment-triggered runs a read-only cache, so a repository reviewed only through /codeboarding starts from the base every time. Co-Authored-By: Claude Opus 5 (1M context) --- README.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index e8310a6..5be2b38 100644 --- a/README.md +++ b/README.md @@ -18,7 +18,7 @@ name: CodeBoarding review on: pull_request: - types: [opened, reopened, ready_for_review] + types: [opened, reopened, ready_for_review, synchronize] issue_comment: types: [created] @@ -44,6 +44,8 @@ jobs: Automatic runs update one sticky **CodeBoarding review** comment. A trusted repository owner, member, or collaborator can comment `/codeboarding` to analyze the current PR head again, including on fork PRs; every command creates a new result comment. +`synchronize` re-runs the review on every push to the branch. Each of those runs covers only the commits pushed since the previous one, so a push costs a fraction of a first analysis — and a pushed commit is the only thing that builds the reusable analysis, since GitHub gives comment-triggered runs a read-only cache. Drop `synchronize` from the list if you would rather spend one analysis per pull request than one per push. + | Command | What it does | |---|---| | `/codeboarding` | Analyzes the current head, reusing this PR's previous analysis when one is available. | From 1ac9399a7da45960ed0393a2a12d782186dc4644 Mon Sep 17 00:00:00 2001 From: Svilen Stefanov Date: Wed, 19 Aug 2026 00:55:13 +0200 Subject: [PATCH 2/2] docs: serialize reviews per pull request alongside per-push runs Recommending a run on every push without a concurrency group invites two races. Two pushes in quick succession analyze concurrently, so both restore the same older analysis and neither continues from the other, which is the saving the per-push recommendation is made for. Worse, every pull_request run writes the same sticky comment header, so whichever run finishes last wins, and that can be the one for the older commit: the review then describes a head that has already been superseded. The example now queues one review per pull request, as this repository's own workflow has done, and says what the alternative costs. Co-Authored-By: Claude Opus 5 (1M context) --- README.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/README.md b/README.md index 5be2b38..a99657e 100644 --- a/README.md +++ b/README.md @@ -28,6 +28,16 @@ permissions: issues: write id-token: write +# One review at a time per pull request. Two pushes in quick succession would +# otherwise analyze concurrently, and both would start from the same older +# analysis instead of the newer one continuing from its predecessor. They also +# share one sticky comment, so whichever finishes last wins — which can be the +# run for the older commit. Queue rather than cancel, so a /codeboarding command +# waits for a running review instead of killing it. +concurrency: + group: codeboarding-${{ github.event.pull_request.number || github.event.issue.number }} + cancel-in-progress: false + jobs: review: if: > @@ -46,6 +56,8 @@ Automatic runs update one sticky **CodeBoarding review** comment. A trusted repo `synchronize` re-runs the review on every push to the branch. Each of those runs covers only the commits pushed since the previous one, so a push costs a fraction of a first analysis — and a pushed commit is the only thing that builds the reusable analysis, since GitHub gives comment-triggered runs a read-only cache. Drop `synchronize` from the list if you would rather spend one analysis per pull request than one per push. +Keep the `concurrency` block if you keep `synchronize`: it is what makes a push continue from the push before it, and what stops a slower run for an older commit from overwriting the review comment for a newer one. Set `cancel-in-progress: true` instead to abandon a superseded run rather than queue it, which costs less when branches are pushed to rapidly, at the price of no analysis for the commits in between. + | Command | What it does | |---|---| | `/codeboarding` | Analyzes the current head, reusing this PR's previous analysis when one is available. |