Restore the Actions bot as the release PR author - #4397
Conversation
PR #4380 switched the `gh pr create` step in the Auto Release PR workflow from the workflow's own GITHUB_TOKEN to a personal access token, and lowered the job permission to `pull-requests: read`. Since then every release PR has carried a person's name as its author instead of the Actions bot, and the automation has depended on one account's credential lifetime. Revert both lines in this workflow. The permission has to go back to `write` because GITHUB_TOKEN needs it to open a PR; `gh pr list` in the earlier step is covered by it. The behavioural cost is documented at the call site rather than silently taken back: a PR opened with GITHUB_TOKEN does not start a `pull_request` workflow run for its `opened` activity, so the release PR opens without API PR CI, CodeQL Advanced, PR Review Bot, and API Migration Check. Later pushes to `develop` do start `synchronize` runs, so a release PR merged before any such push gets no `pull_request` run at all, while one that stays open across further merges does. This was measured on the bot-authored release PRs from before the PAT switch, not inferred: one merged unchanged had no `pull_request` run, another got its runs only once a later merge moved the head, and the PAT-created one got them four seconds after creation. The practical consequence for reviewers is in the comment too: a green release PR does not imply CI ran with `main` as the target. The guards PR #4380 removed from api-pr.yaml stay removed — restoring them would also suppress the `synchronize` runs, which are the only release-PR CI left.
|
Pre-review completed in 4 rounds before this PR was opened, two independent reviewers per round Round 1 — 1 MEDIUM. The comment claimed that Round 2 — 1 LOW. The list of suppressed workflows omitted API Migration Check, which also Round 3 — 3 LOW. "raises no Round 4 — 0 findings from both reviewers. Independently confirmed across rounds: the executable configuration is identical to its state before CI: 11/11 green. |
The comment added in #4397 was wrong. It claimed a PR opened with GITHUB_TOKEN starts no `pull_request` workflow run at all, so the release PR would open with no CI. Checking the Actions history properly shows something different, and the practical advice that followed from it was misleading. What actually happens, verified against run attempt data: - The runs for the `opened` activity are created, but held. Attempt 1 completes as `action_required` with zero jobs, and a manual approval starts attempt 2, which is the one that executes. This follows from the repository's Actions approval policy (`all_external_contributors`), not from the token as such. - Only those runs are held. Later `synchronize` runs from human pushes to `develop` execute on attempt 1, and the PAT-authored release PRs did too. - While a release PR sits unapproved, `develop` push runs for the same head commit do execute and show up green next to the empty PR run records. So a freshly opened release PR shows a mix of pending, jobless entries and real push results. The comment now says that, and tells a reviewer what to do about it: approve the held runs, then confirm that what they are reading belongs to the `pull_request` runs for the current head. Only comments change; the executable configuration is byte-identical. Two earlier attempts at this note were also wrong, in the opposite direction each time. The wording is deliberately narrow now: it names the policy rather than the token, scopes the gate to the `opened` activity, and keeps the same-head push warning from the original note, which was the one part of it that was true.
|
Correction to this PR's description and to the comment it added: the claim that a PR opened with What the table got wrong. Runs were attributed to PRs via a run's What is actually true, verified against run attempt data (a run's top-level
What this PR got right and the first correction attempt then wrongly dropped: while a release PR The configuration change in this PR — bot identity as the release PR author — is unaffected and |
The comment added in #4397 was wrong. It claimed a PR opened with GITHUB_TOKEN starts no `pull_request` workflow run at all, so the release PR would open with no CI. Checking the Actions history properly shows something different, and the practical advice that followed from it was misleading. What actually happens, verified against run attempt data: - The runs for the `opened` activity are created, but held. Attempt 1 completes as `action_required` with zero jobs, and a manual approval starts attempt 2, which is the one that executes. This follows from the repository's Actions approval policy (`all_external_contributors`), not from the token as such. - Only those runs are held. Later `synchronize` runs from human pushes to `develop` execute on attempt 1, and the PAT-authored release PRs did too. - While a release PR sits unapproved, `develop` push runs for the same head commit do execute and show up green next to the empty PR run records. So a freshly opened release PR shows a mix of pending, jobless entries and real push results. The comment now says that, and tells a reviewer what to do about it: approve the held runs, then confirm that what they are reading belongs to the `pull_request` runs for the current head. Only comments change; the executable configuration is byte-identical. Two earlier attempts at this note were also wrong, in the opposite direction each time. The wording is deliberately narrow now: it names the policy rather than the token, scopes the gate to the `opened` activity, and keeps the same-head push warning from the original note, which was the one part of it that was true.
1 participant
Why
Since PR #4380, every release PR (
develop -> main) has been authored by a person instead of theActions bot. That PR switched the
gh pr createstep from the workflow's ownGITHUB_TOKENto apersonal access token and lowered the job permission to
pull-requests: read.Two consequences: an automated PR carries a human's name, and the automation depends on one
account's credential lifetime — when that token expires, release PRs stop appearing with no signal.
What
Reverts both lines in
auto-release-pr.yaml. The permission must go back towrite, sinceGITHUB_TOKENneeds it to open a PR (gh pr listin the earlier step is covered by it). Theexecutable configuration is now identical to its state before #4380; only comments differ.
The guards #4380 removed from
api-pr.yamlstay removed — see below.The cost, documented at the call site
This is a real trade-off and it is written into the workflow rather than quietly taken back. A PR
opened with
GITHUB_TOKENdoes not start apull_requestworkflow run for itsopenedactivity,so the release PR opens without API PR CI, CodeQL Advanced, PR Review Bot, and API
Migration Check (for non-seed
migration/**changes).Later pushes to
developdo startsynchronizeruns. So:pull_requestrun at all;This was measured against the bot-authored release PRs from before the PAT switch, not inferred:
pull_requestrunGITHUB_TOKENGITHUB_TOKENsynchronize)opened)Restoring the
head_ref != 'develop'guards inapi-pr.yamlwould suppress even thesynchronizeruns, which are the only release-PR CI left. So they stay as #4380 left them.
Review note
A green release PR does not mean CI ran with
mainas the target. The checks displayed on itmay come solely from the push runs on
developfor the same head commit. This is now stated in theworkflow comment, but it is worth knowing before approving a release.
If the team would rather keep bot authorship and opened-event CI, the way to get both is a GitHub
App token (
actions/create-github-app-token) instead of either a PAT orGITHUB_TOKEN. That needsan app registration plus
APP_ID/APP_PRIVATE_KEYsecrets, so it is out of scope here.secrets.RELEASE_PR_TOKENis no longer referenced anywhere in the tree; the repository secret andthe underlying PAT can be revoked once this lands.