Sentry Publish 🏠

This is a meta/control repository that implements the Central Publish Repository RFC

Quick Start

craft quick start

Flow Chart

Sequence Diagram

Goals

1. We do not want employees to publish through their own accounts
2. We do not want employees to have access to the global credentials
3. We do not want employees to build and publish releases from their machines
4. We want releases to require formal approvals from a limited set of release managers
5. We want all the above to not discourage from any engineer initiating a release

Usage

1. Go to your repo and trigger the workflow (example: https://github.com/getsentry/sentry/actions/manual?workflow=.github%2Fworkflows%2Frelease.yml)
2. Once the workflow finishes, see the publishing request in this repo (example: #40)
3. Add the accepted label to initiate publishing. Since this action requires elevated permissions, you may need to ask your team lead or manager
4. Observe the issue for information about the triggered run
5. The issue will automatically be closed when publishing succeeds

CalVer

1. You need to add calver: true under the with block of the Prepare release step to enable automatic version determination
2. You also need to add your repository to the list in the calver workflow

Merge Target

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:

1. Update .github/workflows/release.yml by adding code below to on.workflow_dispatch.inputs block:

   merge_target:
     description: Target branch to merge into. Uses the default branch as a fallback (optional)
     required: false

2. In the same file, add merge_target: ${{ github.event.inputs.merge_target }} under the with block of the Prepare release step

Retracting Release Request

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.

Approvals

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.

Under the hood

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.