diff --git a/.github/ISSUE_TEMPLATE/release-checklist.md b/.github/ISSUE_TEMPLATE/release-checklist.md deleted file mode 100644 index b1e94e93..00000000 --- a/.github/ISSUE_TEMPLATE/release-checklist.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -name: Release checklist -about: This is a checklist for maintainers to be used when creating a new release. -title: New release checklist for [version number] (maintainers only). -labels: '' -assignees: '' - ---- -You can see the action released in [here](https://github.com/marketplace/actions/sentry-release). The version shows what was the last released version. - -Checklist for a new release: - -- [ ] Create a PR that bumps the version in `package.json` and merge it - - [ ] Read notes below to figure out which version to pick - - [ ] Make the commit read "Bump version to x.y.z" -- [ ] Once merged, visit the [releases page](https://github.com/getsentry/action-release/releases) - - [ ] Click Draft a new release - - [ ] Create a new tag by entering it in the drop down (see screenshot) - - [ ] Name the release (Use the version number if you want) - - [ ] Describe the release - - [ ] Use the button Generate Release Notes (see screenshot) - - [ ] Update the Full Changelog link to use the right tags (there's a minor bug) - - The first value is the last release; the second value is the tag that has not yet been created, thus, the link won't be working yet -- [ ] Once published, visit [the marketplace](https://github.com/marketplace/actions/sentry-release) to see that the release is showing up -- [ ] Update existing major tag (i.e. v1, v2 etc); Run the following commands - - [ ] `git checkout master && git pull` - - [ ] `git tag -f v` - - [ ] `git push origin master --tags -f` - -**DONE!!** 🎉 - -
- -Screenshot of UI to create tag as part of the release: - -image - -Screenshot of UI to generate release notes: - -image - -### NOTES - -We use semver (x.y.z) versioning. This basically means: -* x bump (breaking compatibility) -* z bump (bug fix/security) -* y bump for everything that does not fall on the other two categories diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index c85e6fa3..b2d41d5b 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,4 +1,7 @@ # Contributing + +See the [development guide](./docs/development.md) for getting started developing this action. + Feel free to use GitHub's pull request features to propose changes. See the [Code of Conduct](https://github.com/getsentry/.github/blob/main/CODE_OF_CONDUCT.md). diff --git a/README.md b/README.md index 64602b1c..3526133c 100644 --- a/README.md +++ b/README.md @@ -10,10 +10,6 @@ # Sentry Release GitHub Action -> [!IMPORTANT] -> This action is currently only available for Linux runners. -> See [this issue](https://github.com/getsentry/action-release/issues/58) for more details. - Automatically create a Sentry release in a workflow. A release is a version of your code that can be deployed to an environment. When you give Sentry information about your releases, you unlock a number of new features: @@ -36,22 +32,7 @@ Please refer to the [release page](https://github.com/getsentry/action-release/r ## Prerequisites -### Create an Organization Auth Token - -For this action to communicate securely with Sentry, you'll need to [create an organization auth token](https://docs.sentry.io/account/auth-tokens/#organization-auth-tokens). - - -You also need to set your Organization and Project slugs and if you're using a self-hosted Sentry instance, provide the URL used to connect to Sentry via SENTRY_URL. - -```bash -SENTRY_AUTH_TOKEN=sntrys_YOUR_TOKEN_HERE -SENTRY_ORG=example-org -SENTRY_PROJECT=example-project -# For self-hosted -# SENTRY_URL=https://my-sentry-url -``` - -We recommend storing these as [encrypted secrets](https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions) on your repository. +See how to [set up the prerequisites](https://docs.sentry.io/product/releases/setup/release-automation/github-actions/#prerequisites) for the Action to securely communicate with Sentry. ## Usage diff --git a/docs/development.md b/docs/development.md index 7bcfb030..d45cc453 100644 --- a/docs/development.md +++ b/docs/development.md @@ -17,8 +17,6 @@ You can run unit tests with `yarn test`. ### E2E testing on GitHub's CI -The first job in [test.yml](../.github/workflows/test.yml) has instructions on how to tweak a job in order to execute your changes as part of the PR. - > [!NOTE] > Contributors will need to create an internal integration in their Sentry org and need to be an admin. > See [#Prerequisites](../README.md#prerequisites). @@ -30,91 +28,24 @@ Members of this repo will not have to set anything up since [the integration](ht > [!NOTE] > This assumes that you have gone through the [#Usage](../README.md#usage) section and have managed to get your GitHub repository to have worked with this action. -> [!NOTE] -> Once we start producing Docker images for PRs we can get rid of the need of using the `sed` command below. - **Step 1** -- Create a branch, make changes and push it -- Run this command, commit the changes and push it - - This will cause the action-release to be built using the `Dockerfile` - - You will need to revert this change once your changes are approved and ready to be merged - -```shell -sed -i .backup 's|docker://ghcr.io/getsentry/action-release-image:latest|Dockerfile|' action.yml -``` +- Create a branch, make changes +- If possible, add unit and E2E tests (inside `.github/workflows/test.yml`) +- Run `yarn install` to install deps +- Run `yarn build` to build the action +- Commit the changes and the build inside `dist/` **Step 2** -Test out your action-release changes on your own repo. - -- Get the sha for the latest commit on **Step 1** -- Modify your usage of action-release to point to that commit (if you're using a fork, edit the `getsentry` org in the string below) - -Example: - -```yml -- name: Sentry Release - uses: getsentry/action-release@ - env: - # You will remove this in the next steps when ready - MOCK: true - SENTRY_AUTH_TOKEN: ${{ secrets.SENTRY_AUTH_TOKEN }} - SENTRY_ORG: ${{ vars.SENTRY_ORG }} - # If you specify a GitHub environment for the branch from where you create - # releases from (e.g. master), you can then specify a repository-level variable - # for all other branches. This allows using a second project for end-to-end testing - SENTRY_PROJECT: ${{ vars.SENTRY_PROJECT }} -``` - -> [!NOTE] -> If you want to locally test the action, read the next section, otherwise, keep reading. - -> [!NOTE] -> Only remove `MOCK: true` once you follow the steps below that will allow you to use two different projects. This will avoid polluting your Sentry releases for your existing Sentry project. - -**Step 3** Create a new Sentry project under your existing Sentry org (only this one time). -**Step 4** -Create an environment variable in GitHub for the branch you release from (e.g. `master`) and define the same variable as a repository variable which all other branches will use (i.e. your PR's branch) - -**Step 5** -Comment out the MOCK env variable from **Step 2**. - -**Step 6** -Push to GitHub and the CI will do an end-to-end run! - -### Local testing via act - -Alternatively, you can test the action locally using [act](https://github.com/nektos/act). - -To get started, you can clone [this sample repo](https://github.com/scefali/github-actions-react/blob/master/.github/workflows/deploy.yml) to test locally. - -**Step 1** -Install `act`. - -```bash -brew install act -``` - -> [!NOTE] -> Make sure you commit your changes in your branch before running `act`. - **Step 3** -Create an integration and set the SENTRY_AUTH_TOKEN (see [#Usage](../README.md#usage)). - -> [!NOTE] -> If you have `direnv` installed, you can define the variable within your repo in an `.env` file. +Create an environment variable in GitHub for the branch you release from (e.g. `master`) and define the same variable as a repository variable which all other branches will use (i.e. your PR's branch) **Step 4** -Run the action. - -```bash -act -s SENTRY_ORG={your_org_slug} -s SENTRY_PROJECT={your_project_slug} -``` +Push to GitHub and the CI will do E2E runs! -> [!NOTE] -> Make sure that `SENTRY_AUTH_TOKEN` is loaded as an env variable. +### Troubleshooting -**Step 5** -Choose Medium Docker builds. +- If the `verify-dist` action fails for your PR, you likely forgot to commit the build output. + Run `yarn install` and `yarn build` and commit the `dist/` folder. diff --git a/docs/publishing-a-release.md b/docs/publishing-a-release.md index 78ff537f..224bf7e9 100644 --- a/docs/publishing-a-release.md +++ b/docs/publishing-a-release.md @@ -1,23 +1,13 @@ -# Publishing a release - -The [build.yml](../.github/workflows/build.yml) workflow will build a Docker image every time a pull request merges to `master` and upload it to [the GitHub registry](https://github.com/orgs/getsentry/packages?repo_name=action-release). - -> [!WARNING] -> Merging pull requests into `master` means changes are live for anyone who uses the action regardless of bumping the version. -> Be extremely careful and intentional with changes and ensure properly testing them before merging, see [#Testing](development.md#testing) for more info. - -> [!NOTE] -> Unfortunately, we only use the `latest` tag for the Docker image, thus, making use of a version with the action ineffective (e.g. `v1` vs `v1.3.0`). -> See #129 on how to fix this. - -> [!NOTE] -> At the moment our Docker image publishing is decoupled from `tag` creation in the repository. -> We should only publish a specific Docker tag when we create a tag (you can make GitHub workflows listen to this). See #102 for details. -> Once this is fixed, merges to `master` will not make the Docker image live. - -When you are ready to make a release, open a [new release checklist issue](https://github.com/getsentry/action-release/issues/new?assignees=&labels=&template=release-checklist.md&title=New+release+checklist+for+%5Bversion+number%5D) and follow the steps in there. - -> [!NOTE] -> At the moment releases are only used to inform users of changes. - -The Docker build is [multi-staged](https://github.com/getsentry/action-release/blob/master/Dockerfile) in order to make the final image used by the action as small as possible to reduce network transfer (use `docker images` to see the sizes of the images). +# Publishing a Release + +_These steps are only relevant to Sentry employees when preparing and publishing a new release._ + +1. Open the [Prepare Release workflow](https://github.com/getsentry/sentry-javascript/actions/workflows/release.yml) and + fill in ![Prepare a Release workflow](../images/prepare_release.png) + 1. Click gray `Run workflow` button + 2. Fill in the version you want to release, e.g. `1.13.3` + 3. Click the green `Run workflow` button +2. A new issue should appear in https://github.com/getsentry/publish/issues. +3. Wait until the CI check runs have finished successfully (there is a link to them in the issue). +4. Once CI passes successfully, ask a member of the + [@getsentry/releases-approvers](https://github.com/orgs/getsentry/teams/release-approvers) to approve the release. diff --git a/images/internal-integration-permissions.png b/images/internal-integration-permissions.png deleted file mode 100644 index 6b04713c..00000000 Binary files a/images/internal-integration-permissions.png and /dev/null differ diff --git a/images/prepare_release.png b/images/prepare_release.png new file mode 100644 index 00000000..33c1e471 Binary files /dev/null and b/images/prepare_release.png differ