Open Wedvich opened 5 months ago
Thanks for reporting this! We need to adjust the endpoint in sentry to work with the org:ci
scope.
@Wedvich could you please try again, but without the cleanArtifacts: true
option, and let us know whether the upload succeeds?
We think that the upload might work without the option, since the endpoint should simply overwrite any existing files with the same name.
Without cleanArtifacts: true
it acts the same way as with it, except it doesn't give the 403. If I run two builds in a row, I now have two artifact bundles under the same release, and both bundles contain the same files/filenames.
Is this intentional behavior? I tried reading the docs on Artifact Bundles but it doesn't say anything about multiple bundles with the same files for the same release?
Is this intentional behavior? I tried reading the docs on Artifact Bundles but it doesn't say anything about multiple bundles with the same files for the same release?
@Wedvich I believe the files that were uploaded last take priority in our resolving logic. But I'll have @Swatinem confirm that!
The logic is indeed very complex and there is way too many moving parts, but we should always prefer the most recently uploaded bundle that contains the file being requested.
If there is some problem with this, can you point me to a specific event and the release with bundles so I can take a closer look?
Thanks for reporting this! We need to adjust the endpoint in sentry to work with the
org:ci
scope.
@lforst your comment really seems to be the root cause, IMO. The suggested method for creating an Auth Token for use in this plugin will only have the org:ci
scope, and it appears that is not sufficient for the delete --all
CLI command it tries to run.
Here are some extra logs showing the command:
sentry-cli was invoked with the following command line: "/app/node_modules/@sentry/cli-linux-x64/bin/sentry-cli" "releases" "files" "some:release-name-here" "delete" "--all"
error: API request failed
caused by: sentry reported an error: You do not have permission to perform this action. (http status: 403)
It appears that the cleanArtifacts: true
will attempt to run that command before uploading the maps. It's nice that the subsequent sourcemap upload succeeds, but it's still not correct that the pre-existing artifacts are not deleted and it's not great seeing errors in the logs.
Hoping for a fix...thanks!
then we need to check if we can adjust the permissions for deleting so that this works with the org based auth token. If you use an old user auth token (Settings -> Account -> API -> User Auth Tokens), does it work then?
then we need to check if we can adjust the permissions for deleting so that this works with the org based auth token. If you use an old user auth token (Settings -> Account -> API -> User Auth Tokens), does it work then?
I/we don't use any User Auth Tokens in these scenarios, so I can't tell you about that specifically, but we do have an organization Custom Integration
setup that we are currently using with the correct permissions where things seem to be working fine.
Hmm yes, afaik these integration tokens and user tokens work very similarly, so that makes sense. Thanks for testing!
Ok so after some pondering we decided to deprecate and delete cleanArtifacts
(for now it will just noop). There was a historical need for it but nowadays you can just override files in Sentry and Sentry will pick up the most recent one for source mapping. For 99.999% of people this should be fine. For all the other users that want to actually delete artifacts from Sentry, it is recommended to use the UI (it is admittedly shitty though), the CLI with a non-organization-auth-token having the right permissions, or by using the API.
Lemme know if you think this is stupid or not 😄
Ok so after some pondering we decided to deprecate and delete
cleanArtifacts
(for now it will just noop). There was a historical need for it but nowadays you can just override files in Sentry and Sentry will pick up the most recent one for source mapping. For 99.999% of people this should be fine. For all the other users that want to actually delete artifacts from Sentry, it is recommended to use the UI (it is admittedly shitty though), the CLI with a non-organization-auth-token having the right permissions, or by using the API.
If what you said is true - that overwritten files will just be picked up/prioritized as one might expect - then I think you're right that this sounds fine for me and probably most users who don't actually really care whether the old files are deleted, as long as having them around:
I personally don't feel like we need our files deleted before a new set of maps are pushed up. Others may disagree but sounds unlikely to me.
Curious as to why the choice to remove/deprecate vs fix? Seems like there are some issues between the various tokens being supported. I have seen (and experienced) some other issues with tokens being rejected by the CLI for not having a valid format sometimes...but for us right now our Custom Integration token seems to work everywhere we need it to.
- Won't cause problems
- Won't end up adding towards some storage quota accidentally and hurting us that way.
It should not cause problems (very generic I know 😄) and sourcemaps also don't count towards any quota and we also do not have plans to make them count towards quota. Enjoy the free storage lol 😄
Curious as to why the choice to remove/deprecate vs fix? Seems like there are some issues between the various tokens being supported.
Exactly. So recently we introduced organization auth tokens with very limited scope to drastically reduce the complexity when setting up source maps. In our documentation, we now heavily tell you to use these new auth tokens because they are much simpler to set up and also have upsides like encoding the org and your self-hosted instance. The thing is, we didn't consider the full capabilities of our bundler plugins, meaning for some features the limited scope of these tokens was not enough. We thought about widening the permissions of the tokens but didn't really want to do that for security reasons, so we instead opted to remove the unnecessary feature.
Gotcha...makes sense. This will be in some upcoming release then?
Thank you for your support and explanations!
@newhouse Yep this will land soon. For now, please just remove the cleanArtifacts
and everything should work.
Environment
Steps to Reproduce
I added
cleanArtifacts: true
to my config, and tried to overwrite the same release name.Expected Result
The existing artifact bundle should be deleted, and the new artifacts should be uploaded. When Webpack is done I expect to only see one artifact bundle under the release.
Actual Result
The upload with the new artifact bundle succeeds, but the old artifacts aren't deleted, and I get the following error in the logs:
I have the Manager role in my Sentry org, and I can manually delete artifact bundles and releases in the Sentry UI.