Closed petschki closed 1 year ago
I also have some repositories where the master branch is protected. But I've allowed repository admins to push anyway. That way repo admins (who are often the ones making the release) can actually release master.
I don't know how to do it otherwise. You'd have to make the release + tag on a branch and then merge it into master after you've already uploaded something to pypi, for instance? Sounds a bit weird.
Ideas welcome of course :-)
Protected master branch makes sense of course. In my case it would have been nice if zest.releaser
would have warned me about an existing protection and that I'm not allowed to push to the master ... is that possible?
I'm afraid we'd have to push something in order to discover if we're allowed to push :) If there's an (http) API for it, it'll be a github-specific API. And then you might run into problems when it is a private repo (if you're using ssh auth for that). So: my guess is that it isn't practical.
The best we can do seems to be to detect the github log message and print a line pointing at a (to be written) section in the documentation.
Do you see other alternatives? @mauritsvanrees?
I see. An other idea would be to let the user choose in postrelease to push the versionbump/changenote updates directly to master or to a new branch (with a sane branchname suggestion like release-x.x.0-bump-x.x.1
or as user input)
I suspect you need to make the choice in the prerelease, already. Otherwise you're making changes on your local master branch that you can't push and have to clean up later.
We could add a setting in setup.cfg
to do it on a branch. I don't want an extra y/n for everybody, of course.
But with a "do it on a branch" setting, also the people that can push to master (because they're admins) are forced to do it on a branch. Or the setting should be "ask if you want to do it on a branch".
Pfffffff.... this is not a problem for which there is an easy and simple solution, I'm afraid. Having a branch laying around which isn't (yet) merged into master but that has already been released also has its drawbacks.
Personally, I'd feel most happy with the "just make the few people that can make a release an admin" solution. Those people also already have pypi access. But I can't oversee all the consequences and effects on a project's organisation. In this case, it seems to be Plone+addons. Can you and @mauritsvanrees come up with a solution? Maurits knows the details about access rights and releases within plone.
An intermediary solution would be to start a branch yourself, by hand, and run "fullrelease" in there.
A setting to warn you "hey, this is a protected project, don't you want to do it on a branch?" could help here. But what would be the default? I guess plone releasers sometimes use the --no-input
option to release a couple of projects at the same time. Their default should be "just do it on master".
Anyway.... more thinkwork needed :-)
Thank you for your feedback on this. Much appreciated. And it's indeed a plone-addon-ish problem because in my case I have pypi access for the package but no admin rights on the repo. Thinking further ... this shouldn't happen in my oppinion and has to be communicated by the plone community what's exactly needed for a person who should be able to do a release... so I'd close this thread here and tend to a non-technical solution by defining the release workflow on plone and/or addon repos (namely pypi access and repo admin rights) ...
maybe there's a plone releaseteam member willing to document this anywhere (or it's already done and I haven't found it?) @mauritsvanrees ?
On zest.releaser's side, there is one question left, then: should we search for the word protected
in the output of the push command? And point at a paragraph of documentation?
In PR #430 I added a bit of documentation that at least mentions the "protected branch" problem.
I've just came across this here:
postrelease cannot push changes to repository if it's protected by a hook ... what can one do in that case?