getsentry/action-release
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

ci: End to end testing (#153)

Browse Source 
For PRs, the CI will create releases under the action-release-prs project while master will create them for the action-release project.

We use different projects since the Release feature does not handle different environments as a way to separate commits. Alternatively, we could have postfixed a different string per PR and use the same project.

Co-authored-by: Kamil Ogórek <[email protected]>
This commit is contained in:
Armen Zambrano G
2023-04-28 13:49:22 -04:00
committed by GitHub
co-authored by Kamil Ogórek
parent 5170344368
commit 3bdd61fc75
3 changed files with 85 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.github/workflows/build.yml
+21 -1
View File
@@ -3,6 +3,14 @@ on:
push:
branches:
- master
env:
# Variables defined in the repository
SENTRY_ORG: ${{ vars.SENTRY_ORG }}
# For master we have an environment variable that selects the action-release project
# instead of action-release-prs
# For other branches: https://sentry-ecosystem.sentry.io/releases/?project=4505075304693760
# For master branch: https://sentry-ecosystem.sentry.io/releases/?project=6576594
SENTRY_PROJECT: ${{ vars.SENTRY_PROJECT }}
jobs:
docker-build:
@@ -11,6 +19,8 @@ jobs:
steps:
- name: Checkout repo
uses: actions/checkout@v3
with:
fetch-depth: 0
# BUILDKIT_INLINE_CACHE creates the image in such a way that you can
# then use --cache-from (think of a remote cache)
@@ -39,4 +49,14 @@ jobs:
run: |
docker login ghcr.io -u $GITHUB_ACTOR --password-stdin <<< ${{ secrets.GITHUB_TOKEN }}
docker push ghcr.io/getsentry/action-release-builder-image:latest
docker push ghcr.io/getsentry/action-release-image:latest
docker push ghcr.io/getsentry/action-release-image:latest
# This step creates real Sentry releases for the action itself:
# https://sentry-ecosystem.sentry.io/releases/?project=6576594
- name: Sentry Release
uses: getsentry/action-release@v1
env:
SENTRY_AUTH_TOKEN: ${{ secrets.SENTRY_AUTH_TOKEN }}
SENTRY_LOG_LEVEL: debug
with:
environment: 'production'
.github/workflows/test.yml
+41 -2
View File
@@ -1,4 +1,4 @@
name: "test"
name: "integration tests"
on:
pull_request:
paths-ignore:
@@ -6,9 +6,48 @@ on:
push:
branches:
- master
env:
# Variables defined in the repository
SENTRY_ORG: ${{ vars.SENTRY_ORG }}
# For master we have an environment variable that selects the action-release project
# instead of action-release-prs
# For other branches: https://sentry-ecosystem.sentry.io/releases/?project=4505075304693760
# For master branch: https://sentry-ecosystem.sentry.io/releases/?project=6576594
SENTRY_PROJECT: ${{ vars.SENTRY_PROJECT }}
jobs:
mock-release: # Make sure that the action works on a clean machine without building
# You're welcome to make changes on this job as part of your PR in order to test out your changes
# We can always undo the changes once we're satisfied with the results
#
# Secrets on this repo do not get shared with PRs opened on a fork, thus,
# add SENTRY_AUTH_TOKEN as a secret to your fork if you want to use this job.
# Checkout the README.md on how to create the internal integration (read: auth token)
create-real-release-per-push:
name: "Test current action"
runs-on: ubuntu-latest
# XXX: This job will fail for forks, skip step on forks and let contributors tweak it when ready
if: github.ref != 'refs/heads/master'
steps:
- uses: actions/checkout@v3
with:
fetch-depth: 0
# For PRs, this supports creating a release using the commits from the branch (rather than the merge commit)
ref: ${{ github.event.pull_request.head.sha || github.sha }}
# This allows executing the action's code in the next step rather than a specific tag
- uses: './.github/actions/use-local-dockerfile'
- name: Create a staging release
uses: ./
env:
# If you want this step to be mocked you can uncomment this variable
# MOCK: true
SENTRY_AUTH_TOKEN: ${{ secrets.SENTRY_AUTH_TOKEN }}
SENTRY_LOG_LEVEL: debug
with:
ignore_missing: true
mock-release: # Make sure that the action works on a clean machine without building Docker
name: "Build image & mock a release"
runs-on: ubuntu-latest
steps:
README.md
+23 -6
View File
@@ -32,7 +32,10 @@ Click “Save” at the bottom of the page and grab your token, which you’ll u
Adding the following to your workflow will create a new Sentry release and tell Sentry that you are deploying to the `production` environment.
```yaml
- uses: actions/checkout@v2
- uses: actions/checkout@v3
with:
fetch-depth: 0
- name: Create Sentry release
uses: getsentry/action-release@v1
env:
@@ -104,8 +107,24 @@ Adding the following to your workflow will create a new Sentry release and tell
## Releases
The `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), thus, effectively being live for everyone even if we do not bump the version.
NOTE: Unfortunately, we only use the `latest` tag for the Docker image, thus, making use of a version with the action innefective (e.g. `v1` vs `v1.3.0`). See #129 on how to fix this.
NOTE: Right now, 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 and the following paragraph will be legit.
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.
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).
### End to end testing on Github's CI
The first job in `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` section above.
Members of this repo will not have to set anything up since [the integration](https://sentry-ecosystem.sentry.io/settings/developer-settings/end-to-end-action-release-integration-416eb2/) is already set-up. Just open the PR and you will see [a release created](https://sentry-ecosystem.sentry.io/releases/?project=4505075304693760) for your PR.
## Development
If your change impacts the options used for the action, you need to update the README.md with the new options.
@@ -140,14 +159,14 @@ Suggestions and issues can be posted on the repository's
Syntax error: end of file unexpected (expecting ")")
```
- When adding the action, make sure to first checkout your repo with `actions/checkout@v2`.
- When adding the action, make sure to first checkout your repo with `actions/checkout@v3`.
Otherwise it could fail at the `propose-version` step with the message:
```text
error: Could not automatically determine release name
```
- In `actions/checkout@v2` the default fetch depth is 1. If you're getting the error message:
- In `actions/checkout@v3` the default fetch depth is 1. If you're getting the error message:
```text
error: Could not find the SHA of the previous release in the git history. Increase your git clone depth.
@@ -156,9 +175,7 @@ Otherwise it could fail at the `propose-version` step with the message:
you can fetch all history for all branches and tags by setting the `fetch-depth` to zero like so:
```text
- uses: actions/checkout@v2
- uses: actions/checkout@v3
with:
fetch-depth: 0
```