Summary
.github/workflows/create-release.yml triggers only on pull_request: types: [closed]. When GitHub drops or never records that event, the release cannot be re-driven: a merged PR cannot be reopened, and the workflow has no workflow_dispatch.
This happened today with 3.1.3. PR #1101 merged cleanly at 16:11 UTC during a GitHub Actions degradation ("We are investigating reports of degraded availability for Actions"). No run record was created for the merge at all — unlike other runs from the same period, which exist and sit in queued, so there is nothing to drain when Actions recovers.
Result: trunk carries the 3.1.3 version bump at a4f8616, and there is no 3.1.3 tag, no GitHub release, and nothing pushed to WordPress.org. The release has to be finished by hand with node scripts/create-release.mjs 1101 plus a separate SVN deploy.
The state is benign — a release that never started rather than one that half-finished — but the recovery path should not be "run the release script off a laptop".
Suggested change
Add workflow_dispatch alongside the existing trigger, taking the release PR number as an input:
on:
pull_request:
types: [closed]
branches: ['trunk']
workflow_dispatch:
inputs:
pr_number:
description: 'Release PR number (e.g. 1101)'
required: trueThree things need adjusting for that to work, because the job currently reads the event payload directly:
- The
if at line 12 (github.event.pull_request.merged == true && startsWith( github.head_ref, 'release/' ) && …) is false for a manual dispatch, so it needs a branch for github.event_name == 'workflow_dispatch'.
github.event.number is used at lines 31, 49 and 63. Those want a single resolved value, e.g. a step output or ${{ github.event.number || inputs.pr_number }}.scripts/create-release.mjs already takes the PR number as process.argv[2] (line 46), so the script itself needs no change.
Worth deciding as part of this: whether a manual dispatch should re-verify that the PR was actually merged and that its head branch started with release/, rather than trusting the operator. The guard exists to stop a non-release PR triggering a deploy, and a hand-typed number bypasses it.
Related
scripts/create-release.mjs is idempotent for a release that already completed — there is a comment at line 52 about skipping the changelog/tag/GitHub steps on a prior run. Worth confirming that holds before relying on re-dispatch, since the whole point is running it a second time.
Suggested labels: enhancement, ready-for-agent.
Summary
.github/workflows/create-release.ymltriggers only onpull_request: types: [closed]. When GitHub drops or never records that event, the release cannot be re-driven: a merged PR cannot be reopened, and the workflow has noworkflow_dispatch.This happened today with 3.1.3. PR #1101 merged cleanly at 16:11 UTC during a GitHub Actions degradation ("We are investigating reports of degraded availability for Actions"). No run record was created for the merge at all — unlike other runs from the same period, which exist and sit in
queued, so there is nothing to drain when Actions recovers.Result:
trunkcarries the 3.1.3 version bump ata4f8616, and there is no3.1.3tag, no GitHub release, and nothing pushed to WordPress.org. The release has to be finished by hand withnode scripts/create-release.mjs 1101plus a separate SVN deploy.The state is benign — a release that never started rather than one that half-finished — but the recovery path should not be "run the release script off a laptop".
Suggested change
Add
workflow_dispatchalongside the existing trigger, taking the release PR number as an input:Three things need adjusting for that to work, because the job currently reads the event payload directly:
ifat line 12 (github.event.pull_request.merged == true && startsWith( github.head_ref, 'release/' ) && …) is false for a manual dispatch, so it needs a branch forgithub.event_name == 'workflow_dispatch'.github.event.numberis used at lines 31, 49 and 63. Those want a single resolved value, e.g. a step output or${{ github.event.number || inputs.pr_number }}.scripts/create-release.mjsalready takes the PR number asprocess.argv[2](line 46), so the script itself needs no change.Worth deciding as part of this: whether a manual dispatch should re-verify that the PR was actually merged and that its head branch started with
release/, rather than trusting the operator. The guard exists to stop a non-release PR triggering a deploy, and a hand-typed number bypasses it.Related
scripts/create-release.mjsis idempotent for a release that already completed — there is a comment at line 52 about skipping the changelog/tag/GitHub steps on a prior run. Worth confirming that holds before relying on re-dispatch, since the whole point is running it a second time.Suggested labels:
enhancement,ready-for-agent.