Closed noslouch closed 8 years ago
I'd been hitting this bug before and switched to an earlier version of the code on @noslouch's branch (the original 632c426 commit). With that commit, I'm able to repeatedly deploy the same release with no problem. In this final merged version, I'm back to failing deploys with 400: Release with version already exists
.
we changed the default value of replaceFiles
to false
. Try adding that config to your config/deploy.js
with a value of true
, so...
sentry: {
replaceFiles: true,
// other config
}
I tried adding that config in my testing earlier today and kept hitting the same issue. I'll take a closer look tomorrow and see if I can isolate it further.
@noslouch actually we changed it back to true
being the default.
Unfotunately I did not see this comment before I released 0.4.0 :-\
Zurp. Woops yeah, true
is the default. What output are you getting when you run with the --verbose
flag?
Might want to try again with replaceFiles
set to false
.
If you have open issues in sentry for the given release, and replaceFiles
is true
, the process will still bork when this tries to delete the files.
It will bork? as in break? Why did we switch to deleting files instead of deleting the release again? I thought the whole point of your PR was to allow reuploading files (by first deleting them) for an already uploaded release with issues assigned
I logged in to my CI server this morning and did a bit more investigation with 0.4.0:
replaceFiles: true
, I get a 400: Release with version already exists
when trying to deploy for a second time. It seems to be attempting to create a duplicate release, despite recognizing that one already exists: https://gist.github.com/reidab/01d8b53a8406acec2f1141155ea2a4cc#file-0-4-0-replacefiles-truereplaceFiles: false
, the deploy succeeds@reidab will investigate soon, seem to work for me all the time... what version of sentry are you running? Or are you using getsentry.com directly?
We're using getsentry.com directly. It may be that the real error is related to deleting or uploading new files, but that it's being masked by this catch
: https://github.com/dschmidt/ember-cli-deploy-sentry/blob/master/index.js#L92
Yeah, I had the same thought, that handleExistingRelease
is erroring somewhere in the delete/upload part, and it's bubbling up to that higher level catch
.
Can you try installing and redeploying with 383beed512f6cb17e29b6084e43d7f2460584979? I added a deeper catch with should log the actual error, instead if allowing it to continue to the createRelease
path.
Okay, that definitely clarifies things. 😌 The real error was a 403 coming back from the file deletions. It's probably worth adding a note to the README that the API key requires project:delete
in addition to project:write
when using replaceFiles
.
Thanks!
Oh that makes sense, yes!
Mind adding a reasonable error message and sending a PR?
In some cases (I can't isolate it yet), when my build server tries to deploy, it's dying if the release already exists, which is puzzling given the order of operations in the
upload
method.I'm trying to isolate, but I thought I'd let you know. See below for output: