Skip to content

ci: create releases with the built-in token instead of the release app #401

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
deanq merged 2 commits into from
Oct 30, 2026
Merged

ci: create releases with the built-in token instead of the release app #401

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
a6720f5
ci: stop requesting issues permission for the release token
justinwlin Oct 30, 2026
090d6f8
ci: create releases with the built-in token instead of the release app
justinwlin Oct 30, 2026
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
20 changes: 5 additions & 15 deletions .github/workflows/release-please.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -27,25 +27,15 @@ jobs:
tag_name: ${{ steps.release.outputs.tag_name }}

steps:
- name: Generate GitHub App Token
id: app-token
uses: actions/create-github-app-token@v2
with:
app-id: ${{ secrets.RELEASE_APP_ID }}
private-key: ${{ secrets.RELEASE_APP_PRIVATE_KEY }}
# Listing permissions limits the token to these. workflows is needed
# to tag a release whose commits change .github/workflows/; if the
# app lacks it, token creation fails here with that permission named.
permission-contents: write
permission-issues: write
permission-pull-requests: write
permission-workflows: write

- name: Run Release Please
uses: google-github-actions/release-please-action@v4
id: release
with:
token: ${{ steps.app-token.outputs.token }}
# The built-in token, as runpod-python uses. The release app lacks the
# workflows permission #399 requested, so its token can't be created.
# The workflow-level permissions grant contents, pull-requests and
# issues write.
token: ${{ secrets.GITHUB_TOKEN }}

@OneAsterisk OneAsterisk Oct 30, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

High: This token will hit the same Resource not accessible by integration that the app token hit in the #397 and #398 runs, so the merge run most likely still won't create v1.21.1.

The check that fails is not "workflow changes in range". It is that the tag's commit has a different .github/workflows/ tree from every branch tip: 50e819a6 is four commits behind main, and #397–#400 changed ci.yml, e2e.yml and release-please.yml. GitHub refuses to create such a ref from any GitHub App token without the workflows permission, and GITHUB_TOKEN cannot have that permission.

Evidence:

Two ways out:

  1. Keep this PR and have a maintainer push the tag from a user account first: git push origin 50e819a65a4b39fa7a198860e1c9f3039fc0cbab:refs/tags/v1.21.1. The create-release API ignores target_commitish when the tag already exists, so no ref is created and the check never runs. release-please then creates the release on the existing tag, release_created is true, and PyPI publish runs.
  2. Or an org owner grants the app Workflows: Read and write and ci: request workflows permission for the release token #399's token step stays, as ci: publish to PyPI from a GitHub-hosted runner #400 asked.

Either way, the "Why this works" and "After merge" sections need rewriting.


pypi-publish:
name: PyPI Publish
Expand Down
Loading