Closed LvffY closed 1 year ago
@mauritsvanrees Did you have time to check on this issue ?
@LvffY Sorry, no not yet. Let me have a look now.
postrelease.py
we call self._push
.baserelease.py
.execute_command
in utils.py
.zest.releaser
command continues.allow_retry=True
to execute_command
. Then the user has to answer a question: do you want to retry, continue, or quit?@reinout We do not actually use this allow_retry
option anywhere, except in utils.txt
where we test that this option works... I think this was mostly meant for retrying an upload, but we have the separate _retry_twine
method for this now.
The easiest solution to the issue here would be to change the _push
method to use allow_retry=True
. Then the user will see that there is an error, and can retry, continue or quit.
I thought this would fail in CI, as this will run in no-input mode, but I see we have set things up so you get a RunTimeError then, so that would work fine.
What do you think?
In this case though, when called from CI, the CI without input would
@LvffY
Second, a feature request Based on this case, it could be great to have a rollback feature, that could allow people to run some code in case of error.
I think the problem here would be: how far do you roll back? Do you revert the postrelease commit? The tag? The release commit? The prerelease commit? Commits by plugins? All of these?
And if you have used this successfully to upload a new release on PyPI, then I would not want to undo any of this. I would want to keep the exact commit and tag that were used to create this release. I can then manually push the changes to a new branch and create a PR, and that will likely solve the problem.
@mauritsvanrees on the rollback feature I think that we want to rollback everything.
You probably want to rollback the upload on the pipy repository as well.
But if the upload on pypi is not "rollbackable", may be you're right and we don't want to rollback anything ?
In this case, may be it could just be a documentation on how to do such a rollback if customer want to do so.
The easiest solution to the issue here would be to change the
_push
method to useallow_retry=True
. Then the user will see that there is an error, and can retry, continue or quit.
Some quick thoughts:
The actual error that you show is caused by insufficient rights due to a protected main branch. That's actually a nasty problem. The ones making releases have to be admins that are allowed to circumvent the protection. My assumption is pretty much that the ones with pypi upload rights also have git push rights.
Anyway, such a protection isn't something that a retry is going to help with. Though... you could get someone to give you the rights and then retry it. So: the retry seems like a good idea.
I have a PR #430 that (mostly) fixes this, I hope.
First of all : thanks for your tool :)
First, my issue
During a release, if a push fails, the release does not fail. This can make false positive CI/CD builds (i.e the pipeline return as green but the push did not went well, so it's in fact, a red pipeline).
Reproduce steps
fullrelease --no-input
Expected result
The release should me marked as failed
Actual result
The release is marked as succeeded.
Here is the logs that I get :
fullrelease --no-input
git tag test
then try to push withgit push origin my-branch --tags
we can see that my command return a non-zero return codeSecond, a feature request
Based on this case, it could be great to have a rollback feature, that could allow people to run some code in case of error.
I think that a default implementation could be :
if something went wrong, try to remove the supposed created tag and, why not, the uploaded artifact