Feature request: Support git push options

[JackCuthbert]

Problem

My team has a bit of an interesting versioning setup in GitLab CI/CD where we:

1. Don't want to run a pipeline on the version bump commit on a development branch
2. Want to run a pipeline on the version bump commit once it makes it into a primary (master) branch

Adding [skip ci] to every commit means we need to manually run pipelines after merges if the version bump commit is the most recent commit after a merge.

Proposal

GitLab supports a ci.skip option that when combined with this plugin should allow us to achieve both scenarios when we:

1. omit the [skip ci] string from the commit message template
2. configure @semantic-release/git to use the ci.skip push option

Version commits to our develop branch won't be built, and merges to our master/production branches will.

This support should still mean that this plugin is CI agnostic as push options is a git feature rather than a GitLab feature and not required at all.

I'm happy to make a PR for this if it sounds like something that this plugin should support. It looks like I'd need to pass through any push options to the push() method here and here.

Thanks 😄

[pvdlg]

It seems the --push-option has been added in Git 2.10.2, however we currently support git 2.0.0 and higher, so would be able to use this feature without a breaking change.

Do you know if there is other CIs that support such option? We might consider increasing our minimum Git version if this is a commonly used feature.

In the meantime I would recommend to set the push.pushOption config variable in your CI with git config.

[JackCuthbert]

Do you know if there is other CIs that support such option? We might consider increasing our minimum Git version if this is a commonly used feature.

At this time I've only looked into it on GitLab CI as that's what we're using. A quick google suggests that GL is likely the only big platform that has features around push options.

In the meantime I would recommend to set the push.pushOption config variable in your CI with git config.

Good idea! I didn't think of this 😄

[pvdlg]

Thinking about this issue, I'm not really to understand how you end up in this situation...
When you merge to master how come the head is a commit with ci skip? Shouldn't the new head of master be a merge commit resulting from the merge? And shouldn't that commit trigger your CI?

[JackCuthbert]

We don't use merge commits, only fast-forward merges.

We're very strict in using conventional/atomic commits and the gitflow workflow that works for our release schedule/org comms. We like semantic-release because we don't have to do a lot of the manual work that gitflow usually requires when creating releases. It means we can have a super clean git history and CI pipeline with no manual intervention.

[pvdlg]

For info we don't recommend using semantic-release with Git Flow. See semantic-release/semantic-release#1231 (comment)

The goal of semantic-release is to continuously deliver. As such any commit that end up on the release branch (master by default) is considered releasable and is released. Gitflow does the exact opposite and "store" commits on a release branch before actually releasing.

I'm sure there is way to force semantic-release to fit in GitFlow, but I wouldn't recommend it. If you want a tool that only automate some tasks and doesn't take over the whole release process for you, including the decision to make a release or not, I would suggest to look to other more limited tools doing those specific automation tasks.

[JackCuthbert]

Roger that, completely understand. If it was up to me we'd be doing proper continuous delivery 😛 but the powers that be require delayed releases. Thanks for your time, @pvdlg.

[flaval]

I found this issue because my team and I are in the same situation : using this fantastic tool semantic-release while we use a "Git Flow-like" workflow pattern and we use fast forward merge only for clearer git history. Although you don't recommend using Git Flow with semantic-release, in fact semantic-release is quite flexible to be configured with Git Flow pattern.

Despite this question, actually in February 2021, do this plugin still support git 2.0.0, so the --push-option solution still not conceivable ?
I thought to an additional option skip or skipCi which can take values between message, push-option or false, with the message default value for avoid breaking change. This solution brings the possibility to avoid the "[skip ci]" string in commit message without have to pass a custom message option and copy/paste the default message commit omitting this specific "[skip ci]" letters.

I can do a PR for this proposal (I was ready to do it, but in last minute I wanted to check if the solution was not already proposed, and I found this issue 🙂)

I'm sorry for my English, I use and abuse Google Translate to write this comment