Skip to content

Add an action that keeps the self-review labels in step with the code - #7

Draft
SirCotare wants to merge 8 commits into
mainfrom
github-pr-review-freshness
Draft

SirCotare wants to merge 8 commits into
mainfrom
github-pr-review-freshness

Conversation

@SirCotare

@SirCotare SirCotare commented Oct 5, 2026 •

Copy link
Copy Markdown
Member

Adds github-pr-review-freshness, which keeps two labels true to the code after a self-review. aboutbits/agent-kit#10 writes the marker and sets risk:low; the reviewer guide in aboutbits/agent-kit#11 reads self-review:stale. Without the action, a push after the review keeps risk:low, and the PR can merge on green with unreviewed code.

  • It runs on opened, reopened, synchronize, edited and labeled, when the body has a self-review marker or the PR carries one of the two labels.
  • It computes the branch id and compares it with the one in the PR body's hidden <!-- self-review: <sha> <branch-id> --> marker. A rebase keeps the id; a change to the reviewed code does not.
  • When the ids differ, it removes risk:low and adds self-review:stale. When they match again, it removes self-review:stale. Without a marker, it removes both.
  • On the top PR of a stack reviewed whole, the marker names the stack's base (base=<branch>), and the action compares from there.
  • Each run reads the PR as it is when the run starts, not as the event saw it, and in the example a newer check cancels the one still running for the same PR. One gh pr edit fires edited and labeled at once; before, the second run failed on GitHub's 404, and a run for a push could act on an old marker and leave risk:low next to self-review:stale.

Review notes

  • branch-id.js must compute exactly what review-state.ts in aboutbits/agent-kit computes. Both run every diff with fixed options, so a machine's git config cannot change an id, and both give a binary file its blob id.
  • The action owns self-review:stale in both directions; pr-ready neither sets nor removes it.
Test scope
  • Ran: the branch id from branch-id.js against the TypeScript one on five repositories: agent-kit, transcon-api#193, an emva-erp-api branch with 91 files, and two small ones with binary files, renames and diff.algorithm=histogram. The action's script against mocked GitHub calls, in eight cases, among them an event that saw an old marker, a head that moved on, and a label another run already removed. On GitHub: finstral-composer-api and finstral-composer-web have used the action from this branch since 12 October.
  • Not run: two runs racing on GitHub after this change.

🤖 Generated with Claude Code

It removes the label when the PR's branch id differs from the one the self-review wrote into
the PR body. The id is computed like the self-review skill of aboutbits/agent-kit does it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@SirCotare SirCotare self-assigned this Oct 5, 2026
SirCotare and others added 2 commits October 6, 2026 16:44
…he self-review

The label shows in the PR list, so a reviewer sees a stale self-review without opening anything.
The action owns it in both directions: it adds it when the change differs from the marker, and
removes it when a new round makes the marker current again or the marker is gone.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…nd every id

Mirrors aboutbits/agent-kit's review-state.ts. A changed binary file had an empty id, and a
machine's diff.algorithm or diff.renames could change an id.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@SirCotare SirCotare changed the title Add an action that keeps risk:low only on reviewed code Add an action that keeps the self-review labels in step with the code Oct 6, 2026
Comment thread readme.md Outdated
contains(github.event.pull_request.body, '<!-- self-review:')
|| contains(github.event.pull_request.labels.*.name, 'risk:low')
|| contains(github.event.pull_request.labels.*.name, 'self-review:stale')
runs-on: ubuntu-latest

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We do not pin to latest, as the upcoming 24.04 -> 26.04 switch from GitHub shows.
This should be a controller migration.

But for the sake of this action, you can keep latest if you want.
You decide.

Suggested change
runs-on: ubuntu-latest
runs-on: ubuntu-26.04

@SirCotare SirCotare Oct 7, 2026 •

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A version in the readme goes stale, and people copy the example as it is. So the example now leaves runs-on out, with a comment that says what to put there: GitHub rejects the copied workflow at once until the dev adds the runner their repository uses. A made-up label like ubuntu-<version> would not fail at once. The job would wait 24 hours for a runner, and the labels would silently stop being updated.

SirCotare and others added 5 commits October 7, 2026 18:05
…ev picks one

A version in the readme goes stale, and the example is copied as it is.
An unknown name in the expression fails the workflow at once; a made-up
runner label would wait 24 hours for a runner instead.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… put there

Without runs-on, GitHub rejects the copied workflow at once with
"Required property is missing: runs-on", and the comment says what to add.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…arker names one

The self-review can review a stack of pull requests whole. Then only the
top pull request may carry risk:low, and its marker names the stack's
base, so a change anywhere in the stack, once restacked into the top,
removes the label.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
One gh pr edit that changed the body and added a label fired an edited and a labeled run at the
same second. Both removed self-review:stale, and the second failed on GitHub's 404. Worse, a run
decided on the body and the labels the event carried: a run for a push could still see the old
marker after pr-ready wrote the new one, and leave risk:low next to self-review:stale.

The run now reads the pull request when it starts and checks out its current head, leaves the
labels to a newer push's run when the head moved on, and treats a label that is already gone as
removed. The example gives the job a concurrency group per pull request.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The newer run reads the pull request later, so its state is the more recent one, and the running
one stops before the newer one starts.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants