You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* chore(release): Add craft publish workflow
Previously, any push to `master` built and uploaded the action's underlying
docker image to the GitHub registry under the `latest` tag. That meant,
regardless of version specified in a user's workflow they'd get the latest
change.
The introduction of craft allows us to push versioned images to the registry and
associate a release's action with that version.
At the moment, this workflow does not incorporate tags for major (e.g. `v1`) and
major.minor (e.g. `v1.2`). The ability to publish several git tags will probably
have to be added to craft or publish directly.
Closes: #129
* Revert action to use `latest` tag as we don't yet have any versioned images
published
* Update CHANGELOG.md
Co-authored-by: Lukas Stracke <lukas.stracke@sentry.io>
* Update .github/workflows/release.yml
Co-authored-by: Lukas Stracke <lukas.stracke@sentry.io>
---------
Co-authored-by: Lukas Stracke <lukas.stracke@sentry.io>
sed "s|docker://ghcr.io/getsentry/action-release-image:latest|Dockerfile|" ${{inputs.working_directory}}/previous.yml >> ${{inputs.working_directory}}/action.yml
15
+
sed "s|docker://ghcr.io/getsentry/action-release-image:.*[^']|Dockerfile|" ${{inputs.working_directory}}/previous.yml >> ${{inputs.working_directory}}/action.yml
-**feat(sourcemaps): Add inject option to inject debug ids into source files and sourcemaps (#229) **
11
+
A new option to inject Debug IDs into source files and sourcemaps was added to the action to ensure proper un-minifaction of your stacktraces. We strongly recommend enabling this by setting inject: true in your action alongside providing a path to sourcemaps.
12
+
13
+
** Other Changes **
14
+
- feat(telemetry): Collect project specific tags (#228)
15
+
16
+
## Previous Releases
17
+
18
+
For previous releases, check the [Github Releases](https://github.com/getsentry/action-release/releases) page.
Copy file name to clipboardExpand all lines: docs/development.md
+22-20Lines changed: 22 additions & 20 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
# Development of `getsentry/action-release`
2
2
3
-
This document aims to provide guidelines for maintainers and contains information on how to develop and test this action.
3
+
This document aims to provide guidelines for maintainers and contains information on how to develop and test this action.
4
4
For info on how to release changes, follow [publishing-a-release](publishing-a-release.md).
5
5
6
6
## Development
@@ -20,7 +20,7 @@ You can run unit tests with `yarn test`.
20
20
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.
21
21
22
22
> [!NOTE]
23
-
> Contributors will need to create an internal integration in their Sentry org and need to be an admin.
23
+
> Contributors will need to create an internal integration in their Sentry org and need to be an admin.
24
24
> See [#Prerequisites](../README.md#prerequisites).
25
25
26
26
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.
@@ -33,35 +33,37 @@ Members of this repo will not have to set anything up since [the integration](ht
33
33
> [!NOTE]
34
34
> Once we start producing Docker images for PRs we can get rid of the need of using the `sed` command below.
35
35
36
-
**Step 1**
37
-
* Create a branch, make changes and push it
38
-
* Run this command, commit the changes and push it
39
-
* This will cause the action-release to be built using the `Dockerfile`
40
-
* You will need to revert this change once your changes are approved and ready to be merged
36
+
**Step 1**
37
+
38
+
- Create a branch, make changes and push it
39
+
- Run this command, commit the changes and push it
40
+
- This will cause the action-release to be built using the `Dockerfile`
41
+
- You will need to revert this change once your changes are approved and ready to be merged
41
42
42
43
```shell
43
44
sed -i .backup 's|docker://ghcr.io/getsentry/action-release-image:latest|Dockerfile|' action.yml
44
45
```
45
46
46
47
**Step 2**
47
48
Test out your action-release changes on your own repo.
48
-
* Get the sha for the latest commit on **Step 1**
49
-
* 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)
49
+
50
+
- Get the sha for the latest commit on **Step 1**
51
+
- 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)
Copy file name to clipboardExpand all lines: docs/publishing-a-release.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,12 +7,12 @@ The [build.yml](../.github/workflows/build.yml) workflow will build a Docker ima
7
7
> Be extremely careful and intentional with changes and ensure properly testing them before merging, see [#Testing](development.md#testing) for more info.
8
8
9
9
> [!NOTE]
10
-
> 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`).
10
+
> 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`).
11
11
> See #129 on how to fix this.
12
12
13
13
> [!NOTE]
14
-
> At the moment our Docker image publishing is decoupled from `tag` creation in the repository.
15
-
> 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.
14
+
> At the moment our Docker image publishing is decoupled from `tag` creation in the repository.
15
+
> 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.
16
16
> Once this is fixed, merges to `master` will not make the Docker image live.
17
17
18
18
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.
0 commit comments