This is a meta/control repository that implements the Central Publish Repository RFC
- We do not want employees to publish through their own accounts
- We do not want employees to have access to the global credentials
- We do not want employees to build and publish releases from their machines
- We want releases to require formal approvals from a limited set of release managers
- We want all the above to not discourage from any engineer initiating a release
- Go to your repo and trigger the workflow (example: https://github.com/getsentry/sentry/actions/manual?workflow=.github%2Fworkflows%2Frelease.yml)
- Once the workflow finishes, see the publishing request in this repo (example: #40)
- Add the
accepted
label to initiate publishing. Since this action requires elevated permissions, you may need to ask your team lead or manager - Observe the issue for information about the triggered run
- The issue will automatically be closed when publishing succeeds
- You need to add
calver: true
under thewith
block of thePrepare release
step to enable automatic version determination - You also need to add your repository to the list in the
calver workflow
By default, all releases will be merged to the default branch of your repository (usually master
or main
). If you want to be able to override this behavior, you need to perform additional steps listed below:
- Update
.github/workflows/release.yml
by adding code below toon.workflow_dispatch.inputs
block:merge_target: description: Target branch to merge into. Uses the default branch as a fallback (optional) required: false
- In the same file, add
merge_target: ${{ github.event.inputs.merge_target }}
under thewith
block of thePrepare release
step
To retract a release request, comment #retract
(as the only comment content) under the request you want to retract.
The only person that can do retract a release, is the same person that initially requested it and is listed in the request description.
Packages we release into the wider world that our customers install, require an explicit approval. This for instance applies to
sentry-cli
, our SDKs or the symbolicator
distributed utilities. Internal dependencies such as arroyo
can be published
with an auto approval. The reasoning here is that the bump of the dependency requires an explicit approval again in Sentry
proper. In theory if an independent package gets sufficient independent use of Sentry we might want to reconsider an auto
approval process for such package as it might become an interesting target for an attacker.
Automatic approvals are managed in the auto-approve.yml
workflow.
The system uses Craft under the hood to prepare and publish releases. It uses GH_SENTRY_BOT_PAT
personal access token, tied to the getsentry-bot account to perform repository actions automatically. This account is a member of the release-bot team. The reason for using a team is to ease role-based ACLs and making the rotation of the bot account itself if/when needed.
This repo is read-only for everyone except for release managers. This is because all sensitive secrets such as admin-level GitHub access tokens or package repository publishing tokens (npm, PyPI, cargo, etc.) are defined in this repository as secrets and anyone with write access can create or trigger an arbitrary GitHub action workflow, exposing these secrets without any indication. See getsentry/sentry#21930 for an example.
Due to the same reason above, action-prepare-release needs yet another bot account, getsentry-release that is defined as a regular member of the engineering team to have read access to this private repo. This is to automatically create publish request issues from the action. We cannot use GITHUB_TOKEN
for these actions as GitHub prevents triggering more workflows via this token. The access token for this account is called GH_RELEASE_PAT
and it is defined at the organization level.