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.

[dataflake]

I'd like to take this up again and do manual testing with a user account I will create for this purpose named "dataflaketest". I have semi-randomly chosen the repository for the Missing package to test the workflow shown below.

From what I have read from others the process breaks down on step 4. Right now only organization/repo admins can successfully push to the master branch without creating yet another development branch, having that reviewed and merging it to master.

Example: @mauritsvanrees had to create zopefoundation/Products.CMFCore#159 even though the branch protection rule for the master branch says the organization group "Release Managers" can bypass the required PR process. @mauritsvanrees is a member of that group.

If you get emails about a member "dataflaketest" being added to teams or doing pushes and releases for the Missing package, that's just me.

Standard bug fix workflow

1. developer creates a branch to work on a bug fix
2. developer creates a PR against the main/master branch
3. after successful review (including conversation resolution, test success) developer merges the branch into master
4. release manager pushes the changes required for a release like version number change, change log update to the main/master branch
5. release manager creates a release and uploads to PyPI
6. release manager pushes the post-release changes like version number change, change log update to the main/master branch

[mauritsvanrees]

I use the fullrelease command from zest.releaser, and that slightly changes steps 4-6, though not significantly:

4. release manager commits changes required for a release, and creates a tag
5. release manager creates a release and uploads to PyPI
6. release manager commits the post-release changes like version number change
7. release manager pushes to GitHub: all changes to main/master and the new tag

In step 7, pushing the tag works, but updating main/master fails.
Presumably, since the tag is there, at least the prerelease commits have been successfully pushed.

[dataflake]

I think I have figured this out. At a minimum, the page to edit branch protection rules is confusing, if not misleading.

If you look at https://github.com/zopefoundation/Missing/settings/branch_protection_rules/31002891 you see that I have configured the zopefoundation/release-managers group for "Allow specified actors to bypass required pull requests". But that doesn't do what it claims. My pushes from the dataflaketest account, which is a member of zopefoundation/release-managers, still yielded this:

$ git push
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 16 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 1010 bytes | 1010.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
remote: error: GH006: Protected branch update failed for refs/heads/master.
remote:
remote: - 5 of 5 required status checks are expected.
To https://github.com/zopefoundation/Missing.git
 ! [remote rejected] master -> master (protected branch hook declined)
error: failed to push some refs to 'https://github.com/zopefoundation/Missing.git'

Matter of fact, there doesn't seem to be any setting on that page - other than completely removing branch protection - that would allow members of zopefoundation/release-managers to use the standard zest.releaser set of steps.

Then I found out there's a GitHub organization-level permission named "Bypass branch protections". That actually does what we want. It's not possible to assign a permission to a user or team directly and since this is a non-paid GitHub plan I can't create a custom role that includes the desired permission but leaves out a bunch of other admin-level permissions, so I had to assign the built-in role "All-repository admin" to the release manager team. I find that very unsatisfactory because now all release managers have permissions far exceeding this actual role description, but it seems that's the only way.

So the upshot is that the zest.releaser workflow, specifically the pushes to the master branch, will work now. But the price is a loss of organizational access control.

Just as a reminder, the current release manager team members are @icemac, @mauritsvanrees, @davisagli, @d-maurer and me. Since it's now a lot more powerful I'd like to keep this team small.

[mauritsvanrees]

I wonder if this would work better with rulesets instead of branch protection rules.
Especially the "restrict updates" setting: "If selected, only users with bypass permissions can push to branches or tags whose name matches the pattern you specify."

Rulesets are a more recent addition, so maybe they work better here. But that is a guess.

[mauritsvanrees]

Ah, one other thing I just now notice:

The error you pasted, says:

remote: error: GH006: Protected branch update failed for refs/heads/master.
remote:
remote: - 5 of 5 required status checks are expected.

This differs from "Allow specified actors to bypass required pull requests".

So maybe this is fixed if you also allow the release managers to bypass "Require status checks to pass before merging". But: in a PR you preferably do want those status checks to pass also for release managers. :-/