This exact test works locally when running the workflow manually via node. I suspect we may need to pass in the repo's API token so the workflow can go through its "which files changed since the last release" step, but more testing is necessary to be certain.

Hmm, that's not it, either

If I understand this correctly, what's happening here is that the action always runs from the master branch, so it won't see any changes made in the PR itself.

This makes it impossible to test here (although you should be able to do this on a fork with a merged breaking commit). But it should still fulfill its purpose of a sanity check for state of the branch itself when preparing a release.

I tested this workflow with the addition of

with:
  ref: ${{ github.event.pull_request.head.sha }}

to the "Checkout repository" step on my fork and it behaves correctly.

Manually dispatched workflow failing: https://github.com/WillLillis/tree-sitter/actions/runs/22272379656

Failing in a PR after the label was added: https://github.com/WillLillis/tree-sitter/actions/runs/22272416983/job/64429177745?pr=10

Passing in the same PR after the language crate version was bumped: https://github.com/WillLillis/tree-sitter/actions/runs/22272439586/job/64429243132?pr=10

And here's the PR for reference: WillLillis#10.

There is a chance the workflow may fail prematurely on PRs across forks. This shouldn't happen because of how we've modified our checkout step, but in case it does, the manual dispatch will not run into the same issues (otherwise the action itself would be unsound as we're using it now for real releases).

Sorry, didn't notice before: the trigger needs to be pull_request, not pull_request_target, otherwise it won't see force pushes and other updates to retrigger the check.

Now the check also sees any changes in the pull request, so we can add the language crate bump to the release PR if needed.

Successfully created backport PR for release-0.26:

• ci: retrigger crates check on PR updates #5361