search

saitho / semantic-release-backmerge

:twisted_rightwards_arrows: semantic-release plugin to back-merge a release into a develop branch
https://saitho.github.io/semantic-release-backmerge/
58 stars 11 forks source link

Missing ability to prevent fast-forward merges #34

Closed kyrofa closed 2 years ago

kyrofa commented 2 years ago

First, some details about our setup. Our master branch is our release branch, yes, but instead of immediately pushing it to customers we push it as a release candidate so a few customers can OK it before it rolls to the rest. This means that both develop and master releases are technically prereleases. develop releases look like 2.2.1-edge.1, and master releases look like 2.2.1-rc.1 (until they are approved).

This generally works fine. 2.2.1-edge.1 is built for develop, we merge to master, and that merge commit gets tagged 2.2.1-rc.1. This plugin merges that merge commit back to develop and life goes on. However, it falls down for a specific subset of hotfixes.

When a hotfix is made on master, if master happens to be up to date with develop, this plugin will make a fast-forward merge back to develop. That means that the same commit ends up tagged as both 2.2.1-edge.1 and 2.2.1-rc.1. I'm not sure how semantic-release pulls the tag, but I assume it goes through git describe --tags at some point, which shows 2.2.1-edge.1. That means the next release to master tries to build 2.2.1-rc.1 again, which of course already exists.

I was hoping for a way to tell semantic-release-backmerge to use --no-ff when backmerging. Any chance that would be acceptable? Happy to do the work if so.

kyrofa commented 2 years ago

Scratch this. I dug into the code. Semantic release actually leans really heavily on git notes, and it turns out that my channel setup needed some work. This is working fine, I think.