fix: trigger PyPI publish/deploy by authoring releases with the DS_RELEASE_BOT app token#1407
Open
lhoupert wants to merge 3 commits into
Open
fix: trigger PyPI publish/deploy by authoring releases with the DS_RELEASE_BOT app token#1407lhoupert wants to merge 3 commits into
lhoupert wants to merge 3 commits into
Conversation
Releases created by release-please using the default GITHUB_TOKEN are authored by github-actions[bot]. GitHub deliberately does not trigger new workflow runs from events caused by the default GITHUB_TOKEN (anti-recursion), so the `release: published` event never fired for bot-created releases. As a result the build / upload_pypi jobs (gated on `github.event_name == 'release'`) and the deploy.yml workflow were skipped, and 2.0.3 was never published to PyPI nor deployed. Mint a short-lived GitHub App installation token in the release-please job and pass it to the action so the release is authored by the App. Events from an App token DO create new workflow runs, so the existing publish + deploy workflows cascade automatically — no rewrite of build/upload/deploy needed. Requires repo/org secrets RELEASE_APP_ID and RELEASE_APP_KEY (see #1406); inert until those exist. Refs #1406 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3 tasks
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
Set explicit permission-contents/permission-pull-requests on the create-github-app-token step so the minted token does not inherit the App installation's blanket permissions (zizmor: dangerous use of GitHub App tokens). release-please only needs Contents (tags/releases) and Pull requests (release PR). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Contributor
Author
|
Addressed the zizmor code-scanning finding ("app token inherits blanket installation permissions") in e3e56ca: the permission-contents: write
permission-pull-requests: writeso it no longer inherits the App installation's full permission set. release-please only needs Contents (tags/releases) + Pull requests (release PR). zizmor passes locally; the code-scanning alert should clear on the next scan. |
developmentseed already has an org-level GitHub App for release automation (secrets DS_RELEASE_BOT_ID / DS_RELEASE_BOT_PRIVATE_KEY). Use those instead of provisioning a new App, so no new secrets are needed and the workflow is no longer blocked. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
lhoupert
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this does
Fixes #1406: bot-authored releases never trigger PyPI publish/deploy.
release-please currently uses the default
GITHUB_TOKEN, so releases are authored bygithub-actions[bot]. GitHub does not cascade workflow runs from default-GITHUB_TOKENevents (anti-recursion), sorelease: publishednever fired for 2.0.3 →build/upload_pypi(gated ongithub.event_name == 'release') anddeploy.ymlwere skipped, and 2.0.3 was never published.This mints a short-lived GitHub App installation token and passes it to
release-please-action. Events from an App token do create new workflow runs, so the existing publish + deploy workflows cascade automatically — no change tobuild,upload_pypi, ordeploy.yml.Uses the existing org-level release App (secrets
DS_RELEASE_BOT_ID/DS_RELEASE_BOT_PRIVATE_KEY) — no new App or secrets needed. The minted token is scoped to least privilege (Contents + Pull requests, R/W) so it doesn't inherit the App's blanket installation permissions.Changes
.github/workflows/release.yml: addactions/create-github-app-token(SHA-pinned, v2.2.2) step usingDS_RELEASE_BOT_ID/DS_RELEASE_BOT_PRIVATE_KEY, scoped topermission-contents: write+permission-pull-requests: write; pass its token to release-please instead ofsecrets.GITHUB_TOKEN.RELEASING.md: document that the release is authored via the App token, which is what makes publish/deploy trigger.Before merge — verify (org admin)
DS_RELEASE_BOTApp is installed on this repo and has Contents: R/W + Pull requests: R/W.DS_RELEASE_BOT_ID/DS_RELEASE_BOT_PRIVATE_KEYare visible todevelopmentseed/titiler.Once confirmed, the real test is the next
chore: releasePR: the release should be authored by the App (notgithub-actions[bot]) and publish/deploy automatically.🤖 Generated with Claude Code