Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Protected master branch: create PR #363

Open
d-baer opened this issue Oct 6, 2022 · 5 comments
Open

Protected master branch: create PR #363

d-baer opened this issue Oct 6, 2022 · 5 comments

Comments

@d-baer
Copy link
Contributor

d-baer commented Oct 6, 2022

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-m
Copy link
Owner

@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
Copy link
Contributor Author

d-baer commented Oct 14, 2022

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.

@AdrienHorgnies
Copy link

AdrienHorgnies commented Oct 14, 2022

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-m
Copy link
Owner

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

@jeremybrooks
Copy link

jeremybrooks commented Mar 6, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants