Skip to content

chore: Clean up docs #248

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.

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
merged 2 commits into from
Feb 7, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
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
47 changes: 0 additions & 47 deletions .github/ISSUE_TEMPLATE/release-checklist.md

This file was deleted.

3 changes: 3 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -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).
21 changes: 1 addition & 20 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -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:
Expand All @@ -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

Expand Down
89 changes: 10 additions & 79 deletions docs/development.md
Original file line number Diff line number Diff line change
Expand Up @@ -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).
Expand All @@ -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@<latest commit sha>
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.
36 changes: 13 additions & 23 deletions docs/publishing-a-release.md
Original file line number Diff line number Diff line change
@@ -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.
Binary file removed images/internal-integration-permissions.png
Binary file not shown.
Binary file added images/prepare_release.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.