Skip to content

ci: approve the release pull request's own CI run instead of dispatching one #400

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
futrime merged 1 commit into from
Oct 13, 2026
Merged

ci: approve the release pull request's own CI run instead of dispatching one #400

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 15 additions & 6 deletions .github/workflows/release.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -30,7 +30,7 @@ jobs:
contents: write # the release branch
pull-requests: write # the release pull request
issues: write # the `autorelease:` labels release-please finds its pull requests by
actions: write # to run ci.yml on the release pull request
actions: write # to approve ci.yml's run on the release pull request
steps:
- uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
with:
Expand Down Expand Up @@ -128,10 +128,10 @@ jobs:
npm ci --no-audit --no-fund
node release-pr.js

# A pull request this workflow's token opens or updates starts no `ci-ok` of its own, and
# the branch rule needs one. A dispatch is the one event that token may start. The pull
# request is found by release-please's branch, not its `autorelease: pending` label, which
# it may not have yet; and never dispatched without one, which would run CI on `main`.
# A pull request this workflow's token opens or updates starts ci.yml held for approval,
# and only that run's `ci-ok` lets it merge: a dispatched run's does not count. So it is
# approved here, found by release-please's branch rather than its `autorelease: pending`
# label, which the pull request may not have yet.
- name: Run CI on the release pull request
env:
GH_TOKEN: ${{ github.token }}
Expand All @@ -143,4 +143,13 @@ jobs:
echo "::error::No release pull request is open against $BRANCH."
exit 1
fi
gh workflow run ci.yml --ref "$head" --repo "$GITHUB_REPOSITORY"
for _ in $(seq 30); do
run="$(gh run list --repo "$GITHUB_REPOSITORY" --workflow ci.yml --branch "$head" \
--event pull_request --status action_required --json databaseId --jq '.[0].databaseId // ""')"
if [[ -n "$run" ]]; then
gh api -X POST "repos/$GITHUB_REPOSITORY/actions/runs/$run/approve"
exit 0
fi
sleep 10
done
echo "::warning::No CI run on $head waits for approval: the pull request did not change."
4 changes: 2 additions & 2 deletions docs/contributing/releasing.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -34,8 +34,8 @@ rules as `main`. Three workflows do it:
or, for a new line, since the line before it was cut. A pre-release counts as a last release
only to the pre-releases after it: `0.2.0` says all that changed since `0.1.x`, not just
since `0.2.0-rc.1`.
2. **`ci.yml`** runs on the release pull request, started by `release.yml`: a pull request a
workflow opened starts no checks of its own, and `ci-ok` is needed to merge it. It runs
2. **`ci.yml`** runs on the release pull request, approved by `release.yml`: on a pull request
a workflow opened, it waits for approval, and its `ci-ok` is needed to merge it. It runs
again on every push to a `release/*` branch, the merge included, on what the push changed.
3. **`publish.yml`**, on a push to a `release/*` branch that merged its release pull request,
tags the merge commit `vX.Y.Z`, builds a wheel and an sdist, runs `twine check --strict`
Expand Down
Loading