Only v1 release to point to latest Docker image

[armenzg]

Currently, as soon as we merge code to master, it gets uploaded as the latest Docker image. This means that anyone using the v1 tag will automatically start using it. Expected.

If we have customers using specific versions, they would also start using the latest Docker image. Not expected.

As part of the release process, we should also update the Docker tags. For instance, for release v1.3.0 we should have v1.3 and v1.3.0 Docker images.

As part of the release process, we would then manually trigger a GH workflow that would also publish a v1 Docker image.

@mattgauntseo-sentry does this make sense to you?

[mattgauntseo-sentry]

Just look at this and trying to piece some bits together (I didn't realize the "build" workflow published docker images).

Do you have an example of how people are using a specific version of the docker image? Looking at https://github.com/getsentry/action-release/pkgs/container/action-release-image/versions?filters%5Bversion_type%5D=tagged it looks like we only have the latest tag, does defining anything else work?

It might be helpful to change the release process to automate publishing docker + tags for each part of the version

(i.e. v1.2.3 would result in v1, v1.2, v1.2.3 to be tagged in git and docker.

[armenzg]

Do you have an example of how people are using a specific version of the docker image? Looking at https://github.com/getsentry/action-release/pkgs/container/action-release-image/versions?filters%5Bversion_type%5D=tagged it looks like we only have the latest tag, does defining anything else work?

They can't. This issue is about fixing it. The older images that were downloaded was only during the time I was doing development in the repo. We moved from Docker hub to GHR.

It might be helpful to change the release process to automate publishing docker + tags for each part of the version

(i.e. v1.2.3 would result in v1, v1.2, v1.2.3 to be tagged in git and docker.

That's exactly what I want.

[mattgauntseo-sentry]

s/Technical Debt/Maintenance Load/ 😉

But this sounds like a good change to me, provide plenty of flexibility and consistency.

[deslee]

This is the second time we've had issues with the pipeline and we've had to spend time adding workarounds to upload sourcemaps in our releases. For some reason, starting today we are seeing zero sourcemaps uploaded in our builds, despite the build logs showing the sourcemaps have been uploaded. We really need a way to lock the action to a specific version so this doesn't keep happening

Update: I noticed that beginning with a build on Apr 24, 11:15 PM UTC, there have been two releases created per build. One with parens and one without. No changes have been made to our deployment configs. I'll investigate more, but I believe it has something to do with

[mattgauntseo-sentry]

@deslee Sorry you're running into issues, it might be worth opening in a separate bug.

[mattgauntseo-sentry]

It's finally twigged the pain point that this action has and I'm starting to think we shouldn't have a "latest" tag at all and everything should be built off of the respective tags.

[deslee]

@mattgauntseo-sentry
Update:

I found the cause of the issue. In our github action configuration, we have a version_prefix configured, but our Sentry.init call at runtime did not contain the prefix. Sentry seemed to be able to correlate events at runtime to the build with the version_prefix up until two weeks ago, where it started considering the runtime events as a separate release.

I'm not sure if this is an issue with the github action or with sentry itself. This could also just be the original intended behavior of Sentry (to require the full version in the runtime config) but was working anyway for us until 2 weeks ago... Anyway, adding the prefix to our runtime configuration solved the issue and we are able to see the original sources in our stack trace now