What's the current release procedure?

[agroszer]

Probably missed the message, what's the current release procedure?
Tried to release z3c.rml, tried the good 'ol fullrelease of zest.releaser but can't push the changes to master because

remote: error: GH006: Protected branch update failed for refs/heads/master.
remote: error: 4 of 4 required status checks are expected.
To github.com:zopefoundation/z3c.rml.git
 ! [remote rejected] master -> master (protected branch hook declined)
error: failed to push some refs to 'github.com:zopefoundation/z3c.rml.git'

4.2.1 went out to pypi, then I went through a PR to get the changes to master.

[dataflake]

I don't use zest.releaser so I can't comment on that. In general, there's no universal procedure because master branch protection rules are not the same across all repositories. In this case the CI tests didn't run through. Some repositories also have references to the old Travis CI tests in these branch protection rules, in those cases the condition will never be met until the rule is changed.

[ale-rt]

Given the master branch is protected I guess the best thing you can do is to use a release branch and make a PR.

That means you will have to run something like:

git checkout -b release
git push

and then make a pretty silly PR.

Also I think you have to run

git push --tags

to make the 4.2.1 tag appear on GitHub.

Maybe @icemac has more to say here.

[mgedmin]

We have disabled branch protection rules in the past to allow the zest.releaser workflow. (I don't remember which repo it was, specifically.) It would be my personal preference to continue doing so (although I'm not very active in the Zope world nowadays, so I don't know if my opinion counts for much).

[dataflake]

I'm still unclear why pushing to master didn't work, or maybe I do not understand what zest.releaser does in the background. A manual change and push to master works as I would expect. The push is accepted and the GitHub Actions tests are triggered.

[agroszer]

Looks like it's me, I can't push to master for some reason, neither with a signed commit:

remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
remote: error: GH006: Protected branch update failed for refs/heads/master.
remote: error: 4 of 4 required status checks are expected.
To github.com:zopefoundation/z3c.rml.git
 ! [remote rejected] master -> master (protected branch hook declined)
error: failed to push some refs to 'github.com:zopefoundation/z3c.rml.git'

[mgedmin]

By default people with administrative privileges can ignore branch protection rules and push directly. That's why it works for some people and doesn't work for others.

I've disabled the branch protection for z3c.rml, since we're all consenting adults etc etc. and I didn't see anyone arguing strongly for retaining them in this conversation.

[icemac]

Sorry for being late to the party. 🥳

I think it was mainly me manually activating branch protection for zopefoundation repositories – especially as GitHub nowadays informs me when it is not the case.
Usually I activate

• Require status checks to pass before merging (mostly for lint, docs, coverage, minimum supported Python version, usual Python version (3.10 nowadays) and long running Python version (PyPy3))
• Require conversation resolution before merging

I my mind this allows for clean PRs and gives the ability to use the auto merge feature once the status checks are green and for some repositories the required approvals are gathered.

I see that this is not a good solution for making releases by non-admins. (I see no story at all for this using a protected master branch. Maybe @mauritsvanrees has some experiences or ideas for using zest.releaser in this scenario.)

For z3c.rml I allowed all 197 users in the developers group to write to master. Maybe we have to do this for all repos, so not only the admins have an easy life creating releases. On the other hand: this would make using pull requests optional – I think I could live with this result as we are all adults and have learned to ask for a second opinion or at least for status checks using a PR.