chore: Clean up docs (#248)
* chore: Clean up docs * Use `E2E` consistently in dev docs
This commit is contained in:
Andrei
@@ -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<Major Release Num>`
|
||||
- [ ] `git push origin master --tags -f`
|
||||
|
||||
**DONE!!** 🎉
|
||||
|
||||
<hr/>
|
||||
|
||||
Screenshot of UI to create tag as part of the release:
|
||||
|
||||
<img width="317" alt="image" src="https://user-images.githubusercontent.com/44410/221204718-6fc7b2d8-a8a1-4c13-a626-0fdebff11892.png">
|
||||
|
||||
Screenshot of UI to generate release notes:
|
||||
|
||||
<img width="250" alt="image" src="https://user-images.githubusercontent.com/44410/221206306-bba4a62d-2181-4cad-9285-2aa1a7bde5e8.png">
|
||||
|
||||
### 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
|
||||
@@ -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).
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
+10
-79
@@ -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**
|
||||
**Step 3**
|
||||
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.
|
||||
|
||||
**Step 4**
|
||||
Run the action.
|
||||
Push to GitHub and the CI will do E2E runs!
|
||||
|
||||
```bash
|
||||
act -s SENTRY_ORG={your_org_slug} -s SENTRY_PROJECT={your_project_slug}
|
||||
```
|
||||
### Troubleshooting
|
||||
|
||||
> [!NOTE]
|
||||
> Make sure that `SENTRY_AUTH_TOKEN` is loaded as an env variable.
|
||||
|
||||
**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.
|
||||
|
||||
@@ -1,23 +1,13 @@
|
||||
# Publishing a release
|
||||
# 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).
|
||||
_These steps are only relevant to Sentry employees when preparing and publishing a new 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).
|
||||
1. Open the [Prepare Release workflow](https://github.com/getsentry/sentry-javascript/actions/workflows/release.yml) and
|
||||
fill in 
|
||||
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 not shown.
|
Before Width: | Height: | Size: 29 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 85 KiB |
Reference in New Issue
Block a user