Paul NothaftandPaul Nothaft
b32ba1ed6b
* ci: batch stable releases into one daily version (stable) The stable release PR was auto-merged the instant it went green, so a day with N bugfixes produced N patch releases (3.45.8 AND 3.45.9 on 2026-07-29 alone) — N upgrade notifications for stable users and N full Docker build cycles. Fixes now accumulate in release-please's rolling release PR and are cut as ONE version per day by release-stable-daily.yml (18:00 UTC). Approval/merge mechanics are unchanged from the inline step (#719): approve as github-actions[bot], auto-merge as the PAT so the merge triggers the tag-cutting run. - Urgent fix? workflow_dispatch the daily job or merge the release PR by hand — the schedule is a default, not a gate. - Beta is untouched: instant beta releases are load-bearing for same-day reporter verification. - schedule only fires from the default branch; the stable copy of the new workflow is inert and exists to keep branches in sync. * ci: harden the daily stable-release cut (review round) (stable) Mirror of the #919 hardening — fork-PR head-name spoof (require --base stable + same-repo head) and no longer swallowing the auto-merge-enable failure on the sole automatic stable cut. * ci: accept an immediately-merged release PR as success (review round 2) (stable) Mirror of #919: MERGED state = success (the normal 18:00 case where checks were already green and --auto merges immediately), pending auto-merge = success, still-open-no-auto-merge = real failure. * ci: read release-PR state + auto-merge in one snapshot (review round 3) (stable) Mirror of #919 — collapse the two racing gh pr view calls into one. --------- Co-authored-by: Paul Nothaft <[email protected]>
87 lines
4.6 KiB
YAML
87 lines
4.6 KiB
YAML
name: Cut Stable Release (daily batch)
|
|
|
|
# Stable fixes accumulate in release-please's rolling release PR instead of
|
|
# each cutting its own patch version (the old per-merge auto-merge produced
|
|
# e.g. 3.45.8 AND 3.45.9 on the same day). This workflow merges the open
|
|
# stable release PR once a day, so a day of N bugfixes ships as ONE version
|
|
# with all N changelog entries — and one Docker build instead of N.
|
|
#
|
|
# - schedule only fires from the default branch (main); the stable copy of
|
|
# this file is inert and exists to keep the branches in sync.
|
|
# - Need a release NOW? Run this via workflow_dispatch, or merge the
|
|
# release PR by hand — the schedule is a default, not a gate.
|
|
# - Approval/merge mechanics mirror the old inline step (#719): approve as
|
|
# github-actions[bot] (GITHUB_TOKEN, a valid distinct reviewer), enable
|
|
# auto-merge as the PAT so the merge attributes to a real identity and
|
|
# triggers the tag-cutting run. --auto waits for green checks.
|
|
|
|
on:
|
|
schedule:
|
|
- cron: '0 18 * * *'
|
|
workflow_dispatch:
|
|
|
|
permissions:
|
|
contents: write
|
|
pull-requests: write
|
|
|
|
jobs:
|
|
merge-stable-release-pr:
|
|
runs-on: ubuntu-latest
|
|
steps:
|
|
- name: Approve and enable auto-merge on the open stable release PR
|
|
env:
|
|
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
|
RELEASE_PAT: ${{ secrets.RELEASE_PLEASE_TOKEN }}
|
|
# No checkout — set the repo explicitly so gh works without a
|
|
# git remote (same pattern as whatsnew, 2a5f0a8).
|
|
GH_REPO: ${{ github.repository }}
|
|
run: |
|
|
if [ -z "$RELEASE_PAT" ]; then
|
|
echo "RELEASE_PLEASE_TOKEN not set — skipping (manual review required)."
|
|
exit 0
|
|
fi
|
|
# Strict selection (review P1): this job runs daily even without a
|
|
# stable push, and `gh pr list --head` matches the branch NAME only
|
|
# — a fork PR can spoof `release-please--branches--stable`. Pin the
|
|
# base to stable AND require a same-repo head (isCrossRepository
|
|
# == false); a fork PR is cross-repository, so it can never be
|
|
# picked and auto-merged with the privileged PAT.
|
|
pr=$(gh pr list \
|
|
--base stable \
|
|
--head release-please--branches--stable \
|
|
--state open \
|
|
--json number,isCrossRepository \
|
|
--jq '[.[] | select(.isCrossRepository == false)] | .[0].number // empty')
|
|
if [ -z "$pr" ]; then
|
|
echo "No open same-repo stable release PR — nothing to cut today."
|
|
exit 0
|
|
fi
|
|
# Approve is tolerant — a pre-existing approval already satisfies
|
|
# branch protection and re-approving can return non-zero.
|
|
gh pr review "$pr" --approve --body "Automated approval — daily stable release batch (release-please version bump + changelog)." || echo "::warning::approve returned non-zero (PR may already be approved)"
|
|
# But the auto-merge enable is the load-bearing step: this scheduled
|
|
# job is the ONLY automatic stable cut, so DON'T swallow its failure
|
|
# (review P2) — an expired/under-scoped PAT would otherwise stop
|
|
# releases while the workflow stays green.
|
|
GH_TOKEN="$RELEASE_PAT" gh pr merge "$pr" --squash --auto
|
|
# `gh pr merge --auto` merges IMMEDIATELY when the required checks
|
|
# are already green — the normal case at 18:00, since the fixes
|
|
# merged hours earlier and CI passed. So success is EITHER the PR is
|
|
# already merged OR an auto-merge request is now pending; only a PR
|
|
# that is still open with no auto-merge request is a real failure
|
|
# (expired/under-scoped PAT) worth failing the job on (review round 2).
|
|
# One snapshot of both fields (review round 3): querying state and
|
|
# autoMergeRequest separately races — auto-merge can complete
|
|
# between the two calls, so the first sees OPEN and the second sees
|
|
# the request already cleared on the now-merged PR → false failure.
|
|
read -r state automerge < <(gh pr view "$pr" --json state,autoMergeRequest \
|
|
--jq '[.state, (.autoMergeRequest != null)] | @tsv')
|
|
if [ "$state" = "MERGED" ]; then
|
|
echo "Stable release PR #$pr merged immediately (checks were already green)."
|
|
elif [ "$automerge" = "true" ]; then
|
|
echo "Auto-merge enabled on stable release PR #$pr — merges when checks are green."
|
|
else
|
|
echo "::error::stable release PR #$pr is still open with no auto-merge — check RELEASE_PLEASE_TOKEN scope/expiry."
|
|
exit 1
|
|
fi
|