Protected master branch: create PR

[d-baer]

My master branch at github is protected, changes can only be made via Pull-Requests. With gitflow-maven-plugin gitflow:release I'd like to create a PR from develop to master instead of a push to master.

As far as I understand I could use <gitPushOptions>. Current configuration is:

<gitPushOptions>merge_request.create merge_request.target=master</gitPushOptions>

But I still get:

Failed to execute goal com.amashchenko.maven.plugin:gitflow-maven-plugin:1.18.0:release on project ***: release: remote: error: GH006: Protected branch update failed for refs/heads/master.

Seems like I am missing something.

[Aleksandr Mashchenko]

@d-baer There is skipReleaseMergeProdBranch parameter that you can try to use. But without separate release branch you are probably end up with snapshot version in PR.
Why do you want to call release goal if all you want is to create PR? What benefits of that?

[d-baer]

Thanks @aleksandr-m for your answer. After thinking about my use case, I' d like to rephrase my question. We have a protected master, changes are only allowed via pull requests.

So the question is how to configure gitflow-maven-plugin to work with a protected master. Create release branch from develop via release-start, create PR from that release branch (manually or with gh cli), update dependency to next SNAPSHOT version in develop.

With this configuration

<configuration>
    <pushRemote>true</pushRemote>
    <commitDevelopmentVersionAtStart>true</commitDevelopmentVersionAtStart>
</configuration>

it is possible to create the release branch with release-start, but release-finish wants to push to master which fails of course. Any suggestions on a working configuration? Thx.

[Adrien Horgnies]

The way I set up the CI for my client is that the CI is taking care of running the gitflow plugin, and the CI has the authority to push to the master branch. That's the best way to go about it, in my opinion.

Another way would be not using gitflow for the end of your flow ? Just use the versions plugin to remove the SNAPSHOT suffix of the release branch, create the PR, and then tag.

You can use the plugin parameter skipMergeProdBranch to avoid the problem with master.

[Aleksandr Mashchenko]

@d-baer Can you outline exact steps you want plugin to do in that case?

[Jeremy Brooks]

We have the same use case. Master branches never allow merges without a PR (requirement from SecOps). Essentially we need a PR approved before any merge.

I think the steps would be something like this:
release-start:

• create release branch from develop
• update version in pom.xml
• push release branch to GitHub
• create PR against master

developers now have to approve the PR

release-merge:

• merge the now approved branch to master
• delete release branch
• tag master
• push tags to master
• create PR to merge changes in master to develop

developers now have to approve this PR

release-backmerge

• merge to develop
• create feature branch from develop and update to next SNAPSHOT version
• create PR against develop for developer to approve

developers now have to approve this PR

release-finish:

• merge now approved feature branch to develop
• delete feature branch

@d-baer does this sound right for your use case as well?

For our use case, this requires three separate PR's, since we are required to protect both develop and master branches. Realistically this might be a completely new workflow, maybe a reviewedRelease command rather than modifying the release command. Or it might be that this is just outside the scope of what the plugin is designed to do, and shops that need this level of micromanagement are on their own. :-)