chore: Clean up docs (#248)

* chore: Clean up docs

* Use `E2E` consistently in dev docs

Author: andreiborza

.github/ISSUE_TEMPLATE/release-checklist.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).

CONTRIBUTING.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
 

README.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@<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.

docs/development.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.