search

zestsoftware / zest.releaser

Python software releasing made easy and repeatable
https://zestreleaser.readthedocs.io
GNU General Public License v2.0
198 stars 62 forks source link

postrelease question: what if master branch is protected by a hook? #325

Closed petschki closed 1 year ago

petschki commented 5 years ago

I've just came across this here:

INFO: remote: error: GH006: Protected branch update failed for refs/heads/master.
remote: error: Required status check "continuous-integration/travis-ci" is expected.
To github.com:collective/plone.formwidget.geolocation.git
! [remote rejected] master -> master (protected branch hook declined)

postrelease cannot push changes to repository if it's protected by a hook ... what can one do in that case?

petschki commented 5 years ago

similar: https://github.com/plone/plone.recipe.zope2instance/issues/97#issuecomment-486227088

reinout commented 5 years 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 :-)

petschki commented 5 years ago

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?

reinout commented 5 years ago

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?

petschki commented 5 years ago

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)

reinout commented 5 years ago

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 :-)

petschki commented 5 years ago

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 ?

reinout commented 5 years ago

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?

reinout commented 1 year ago

In PR #430 I added a bit of documentation that at least mentions the "protected branch" problem.