From 181dbd92e51ef5f86db37b0ceebab132cf253d8e Mon Sep 17 00:00:00 2001
From: TaprootFreak <142087526+TaprootFreak@users.noreply.github.com>
Date: Mon, 27 Jul 2026 12:06:55 +0200
Subject: [PATCH] Correct the release PR CI note on the Auto Release PR
 workflow

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.
---
 .github/workflows/auto-release-pr.yaml | 23 +++++++++++------------
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/.github/workflows/auto-release-pr.yaml b/.github/workflows/auto-release-pr.yaml
index bff1b322c8..75d9f42794 100644
--- a/.github/workflows/auto-release-pr.yaml
+++ b/.github/workflows/auto-release-pr.yaml
@@ -53,19 +53,18 @@ jobs:
           # access token would put a human's name on an automated PR and tie the automation to
           # one account's credential lifetime.
           #
-          # Trade-off, deliberately accepted: a PR opened with GITHUB_TOKEN does not start a
-          # `pull_request` workflow run for the `opened` activity. The release PR therefore opens
-          # without any of them — API PR CI, CodeQL Advanced, PR Review Bot, and API Migration
-          # Check when the release carries non-seed `migration/**` changes. 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. Observed on the bot-authored release PRs before this was switched to a PAT:
-          # one merged unchanged had no `pull_request` run, another got its runs only once a
-          # later merge moved the head.
+          # Cost, deliberately accepted: under this repository's Actions approval policy
+          # (`all_external_contributors`), the runs for the `opened` activity — the ones
+          # `github-actions[bot]` triggers by creating the PR — are held. Attempt 1 completes as
+          # `action_required` with zero jobs; a manual approval starts attempt 2, which is what
+          # actually executes. Only those are held: later `synchronize` runs from human pushes to
+          # `develop` execute on attempt 1, and so did the PAT-authored release PRs.
           #
-          # Consequence for reviewers: a green release PR does NOT imply CI ran with `main` as
-          # the target. The checks shown may come solely from the push runs on `develop` for the
-          # same head commit.
+          # Consequence for reviewers: a freshly opened release PR shows a mix. Its pending
+          # `pull_request` entries carry no jobs, while other green checks can be `develop` push
+          # runs for the same head commit — real results, but not PR CI against `main`. Approve
+          # the held runs, then check that what you read belongs to the `pull_request` runs for
+          # the current head.
           GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           COMMIT_COUNT: ${{ steps.check-diff.outputs.commit_count }}
         run: |