fix: CORE4-labelling check - get labels by GitHub API, not event payload

[rtyley]

This change fixes a race-condition that very occasionally causes the CORE4 check to fail on a PR with valid labelling, and continue to fail even if it is re-attempted with multiple job invocations afterwards.

Background

CORE4-labelling check

The CORE4-labelling check was created with PR #105, and updated a little later with PR #108 to accept dependencies as a valid label - because both Dependabot & Scala Steward (as we have it configured) apply that label to their PRs. The CORE4 check was applied to Guardian repos in early December 2025.

Atomicity of creation & labelling of PRs using the GitHub API

When PRs are created through the GitHub API (eg, by Scala Steward), there is no documented way to both create and label them in a single atomic API operation:

• https://github.com/orgs/community/discussions/24724 & https://stackoverflow.com/q/68459601/438886 both declare 2 steps are necessary
• https://docs.github.com/en/rest/pulls/pulls?apiVersion=2022-11-28#create-a-pull-request

...so PRs are first created, and then labelled.

Problem

The CORE4-labelling check currently obtains the labels upon PRs by reading the webhook payload object for pull_request:

.github/.github/workflows/require-label.yaml

Line 16 in 6ba60f6

LABELS: ${{ toJSON(github.event.pull_request.labels.*.name)}}

...but the webhook payload does not change, even if the workflow is manually re-run - only a new webhook event can pick up label changes.

This leads to the rare failure case where a CORE4 check run fails, and continues to fail, on a PR with valid labelling:

1. Bot (Dependabot or Scala Steward) creates the PR (without labels), scheduling CORE4 check run A supplying a payload without labels (eg play-secret-rotation/actions/runs/20428891487)
2. Bot labels the PR milliseconds later, scheduling CORE4 check run B supplying a payload with labels (eg play-secret-rotation/actions/runs/20428891360 - note that surprisingly this run has a lower identifier)
3. CORE4 check run B completes first, and CORE4 check run A completes after (theres always a short, unpredictable delay before scheduled GitHub Action workflow runs are actually allocated on to a action runner) - the final result being, the commit passes - and then fails - its CORE4 check.

...this was seen with this Scala Steward PR, where the CORE4 check failed, and continues to fail:

• Update play to 3.0.10 play-secret-rotation#577

Workaround

Remove the label, wait 10 seconds, and then re-add it. This will create 2 new webhook payloads, and the second - so long as it runs after the first - will have the label in it.

Fix

Use the GitHub API, not the the event payload, to get the labelling information - so simply re-running the GitHub workflow will work to clear any problem - and as the GitHub API information is being generated seconds later than the webhook, it stands more chance of including the applied label.

Testing

Tried out this branch with guardian/play-secret-rotation#580, where it worked well as I added and removed labels - the only difference being, this updated approach would be able to recover by just re-running the job if anything went wrong, rather than toggling the label.

See also

• Update play to 3.0.10 play-secret-rotation#577 (comment)
• https://octokit.github.io/rest.js/v22/#issues-get
• https://github.com/orgs/community/discussions/39062#discussioncomment-4138177
• https://github.com/orgs/community/discussions/24724

[tjsilver]

Looks good. I tested it on the workflow in the PR on actions-static-site (now reverted) and the workflow ran as before (run here). (It did fail due to a permissions error on test-repocop-prs which threw me off a bit at first.) I also tested it on the existing workflow in service-catalogue here. We would need to manually release a new version after this change is merged.

[rtyley]

We would need to manually release a new version after this change is merged.

Thanks @tjsilver ! Is the release process in this repo as simple as adding a new tag and marking it as a GitHub release? I guess for this particular PR it feels like just a 'point' upgrade, ie v2.0.1 after the current v2.0.0 ?