Closed idgserpro closed 5 years ago
Usually for me when a tag already exists, it is because I had fullrelease create this tag a minute ago and something went wrong after that (say problems with PyPI) or I deliberately stopped the process because I noticed something was wrong.
It would be nice to check the result of 'vcs diff' and ask "Do you want to continue" with default answer "No" if we detect a difference. But that is likely tricky to see reliably for git/svn/bzr/mercurial.
Anyway, to answer your question: no, we do not have a modular approach.
When running the automated tests, we read answers from a list that we set in the tests. Theoretically we could enhance this to look for answers to specific questions in setup.cfg
:
[zest.releaser]
answers =
There is already a tag 1.2.7, show if there are differences? = no
The "1.2.7" is dynamic, so we may need to look for questions that start with the given text, like "There is already a tag = no". But then the zest.releaser question may have a typo that we fix, or we want to slightly change the question, so we may need to refer to the question by id, like q_tag_exists
.
In other words: something may be possible here, but it looks tricky.
We're using zest.releaser to automate a bunch of release process and planning to use
no-input = yes
.But in a really rare situation (specially if you don't have a release manager) a wrong merge/rebase can keep in setup.py a release that already exists, and if you're using
no-input = yes
a wrong release is made:Do zest.releaser have a modular approach (like bobtemplates.plone does) to what messages will input yes? In this situation for example it would be nice to abort the process.