Add ability to disable automatic git tag/push

[matejdro]

New feature motivation

Our CI process is part of Jenkins pipeline. Build/test etc. parts are handled by the jenkins and we only use semantic-release to calculate new version number and to generate changelog.

After calculating version numbers, we also perform some changes based on them (such as updating all project files that contain version numbers) and we want to commit them in one big commit instead of one version number commit by sematic release and then another commit with the rest of changes by jenkins.

However, there does not appear to be a way to disable git push functionality. It is hardcoded in index.js

New feature description

Add command line flag or option that would disable automatic git tag and/or push by semantic-release.

[pvdlg]

See #944 and #957 for explanation of why not pushing a tag is not possible.

In your case you should use the @semantic-release/exec plugin to run the script that update your files with the version. You'll have to configure it to run on the prepare step before the @semantic-release/git plugin. Alternatively you can create your own plugin to do that, instead of using @semantic-release/exec.
Then configure the assets option @semantic-release/git to includes your modified files in the commit.

[pvdlg]

Duplicate of #944

[pvdlg]

Duplicate of #957

[matejdro]

I'm aware that tags themselves are mandatory, but it is not mandatory for semantic-commit to push tags itself, it can be done by something else as long as tags are there in the end.

Moving update script to shell file and using exec would needlessly complicate things as all our build process is inside Jenkins pipeline which uses groovy code. Rewriting all that in shell file (or javascript) would cause quite a lot of complications and loose jenkins integration.

I would argue that this is not direct duplicate. #944 was closed due to lack of answers and I did exactly what you asked when closing #944 - create new feature request with those questions answered (I provided reason for disabling git push).

[pvdlg]

I'm aware that tags themselves are mandatory, but it is not mandatory for semantic-commit to push tags itself, it can be done by something else as long as tags are there in the end.

I don't know what semantic-commit is. If you meant semantic-release I think #957 (comment) does explain why it has to be done by semantic-release and not by something else.

Also the statement "as long as tags are there in the end" is incorrect as some publish plugins require to have an existing tag on the remote repository (Atom packages or GitHub releases for example).

Moving update script to shell file and using exec would needlessly complicate things as all our build process is inside Jenkins pipeline which uses groovy code. Rewriting all that in shell file (or javascript) would cause quite a lot of complications and loose jenkins integration.

I understand. However moving out the tag creation logic into something else (which is quite complex with #563) will cause a lot more complications for every other semantic-release users as they would have to handle it themselves.

[matejdro]

Yes, I meant semantic-release, sorry for that.

I think #957 (comment) does explain why it has to be done by semantic-release and not by something else.

In that comment you only explain that semantic-relase requires tags to get latest version which I understand. I just don't see a difference if v2.0.0@next tag is pushed via semantic-release or via any other means that uses same exact git command anyway.

some publish plugins require to

will cause a lot more complications for every other semantic-release users

That is why I request for this to be OPTIONAL option flag. Obviously people that have plugins that require this would not turn this option on.

This feature would only require simple if statement in index.js to disable all git-related functionality. I can add pull request for that if you want.

[pvdlg]

Once #563 is released, tags are created:

• before the prepare step for each version that was merged into the current branch and needs to be added to a distribution channel
• After the prepare step and before the publish step

The correct determination of the last release for the publish step requires the tags created after adding to a channel. So it can't be simply done by the user after semantic-release ran.

Implement what you are requesting would:

• Require to develop the code to handle errors in case the user didn't create the tags properly
• Require to maintain that code
• Require to write the documentation explaining users how to create tags themselves
• Find a way to limit situation where incorrect or partial releases could be published: for example a release without a tag, or vice-versa, or a wrong last release determination
• Complexity and limit future developments as any new feature would have to handle the case of tags not being available after the prepare step
• Create a longer and more confusing documentation for users (users getting confused or not reading the doc completely is by far the majority of tickets and time spend on this project)
• Handle support tickets of users getting themselves in a non recoverable situation, with releases partially done or done incorrectly, due to misconfiguration when using that option
• Handle support tickets of users asking for help about how to create the tag themselves when using that option

And I'm sure I could go on and on... So no, it's not as simple as making that optional even if you write the word optional in capital letters.

And no it's not obvious for users that certain plugins/workflow would not be usable with that option. The plugin concept is that they do not depend on other plugins nor on specific core config.

Your workflow is very specific and I'm pretty sure the very large majority of current or future semantic-release users are not using it. In addition there is a more simple solution, as mentioned before, that consist in wrapping your code that update your project files in something callable via command line and call it with @semantic-release/exec. This can be done with any language and would take less time than implementing what I mentioned above.

So it's a trade-off and I don't think it's worthwhile to try to implement such feature. And I still think it's not even possible without scarifying a lot of current and future more useful features.

If you disagree, I suggest you to fork the project and modify it for your specific needs.

[fastfrwrd]

I'll just note that this feature would also greatly aid us adopting semantic-release. At this point, we'll likely need to create a custom fork of Semantic Release to use internally if this really is non-negotiable.

For some context, we have existing mechanisms we'd like to hook into for the interactions with Git. Git is read-only in our CI system to avoid unpredictable things like writing a new commit in the middle of building an existing one. Our CI team doesn't ever want to make an exception to this, so this check will always fail in our system.

We would get a lot of value out of semantic-release and hook into our existing system quite nicely if we had the option to skip that check. We were planning on doing something like this:

{
  "plugins": [
      "@semantic-release/commit-analyzer",
      "@semantic-release/release-notes-generator",
      "@semantic-release/npm",
      "spotify-specific-ci-plugin-that-triggers-a-tag"
  ]
}

[fastfrwrd]

Elaborating a bit further. The specific thing we want to be able to handle is skipping all communication with the git remote. The commit ends up on our CI machines with the commit history and all tags fetched. This means that fetching, checking that things are up to date is never necessary for us. Analyzing changes and determining a the nextVersion works well. But, the operations push, fetch, verifyAuth, and isBranchUpToDate from lib/git.js are not possible in our system. The tags are pushed to git through an isolated services that only handles pushing tags after a build completes. The point of all of this is never touching git from a build, which our CI team feels very strongly about from a stability standpoint.

This may differ subtly from what the original issue writer wanted, which seems more related to skipping git tag. git tag works fine for us here, which should address some of the concerns brought up above; we eventually re-tag the commit "for real" later in a separate service outside of CI if the CI build says to.

I hacked together a fork of the latest 15.x which comments out the calls I mentioned, and things work great. I'd be happy to put together a PR against 16.x, potentially with the option name --no-git-remote, but it seems that @pvdlg is pretty adamantly against it. I hope that we can somehow find a way to use the main project again in the future; long-stale forks of OSS will almost certainly become huge headaches a few years down the road.

[dominykas]

Could you work around by using a "local" on-disk "remote"?

[fastfrwrd]

@dominykas this approach basically works for us, although it's definitely a hack and it would be great if we could find a way to avoid having to do it.

[darewreck54]

@fastfrwrd Just want to make sure that i'm understanding it correctly. At this time, there is no way to disable the creation of the tag and the push of the tag since it's actually called in the main code base semantic-release/index.js. There is no plugin that can be used to avoid this. So the only way is to basically fork the code and comment out the tagging parts?

I'm basically in the same situation where the Build is decoupled completely from the CI. As a workaround, I just want to use semantic-release to generate and output the version, change-log to a directory. Then the CI will take care of all the rest. But it looks like in order to achieve this, i basically need to fork the code base.

[gr2m]

creating git tags is at the heart of how semantic-release works. If your use case requires you not to do that, then I'm afraid it's out of scope for semantic-release.

[fastfrwrd]

@darewreck54 that's exact boat we were in. We've gotten around it by following the recommendation earlier in this thread to use the local repo as its own remote; it's worked well for months at Spotify, although it's a hack and those of us who know about it are afraid it'll eventually fail to work in a future semantic-release version.

@gr2m we definitely get that tags are core to semantic-release. We forked semantic-release internally but then found that the local origin hack worked well, because the tags are always fine to read in our system, just not to push - git remotes are intentionally unreachable.

Ultimately, we admit we have a uniquely restrictive approach to CI and may just need to figure out something other than semantic-release, but I still do feel it's a pattern you may consider supporting in the future.

[pvdlg]

The tags are required because this how semantic-release figure out what commits were added to the repo since the last release. This is how we determine which commit to analyze and what the next version is going to be.

If your use case is just to output the next version and generate a changelog you might try other tools (such as https://github.com/conventional-changelog/conventional-changelog). But I think you'll probably end up in the same situation, as tools also use tags to figure out what commits were added since the last release.

[dabernathy89]

I'm surprised to see this conversation was left this way. I see variations of this being repeated:

The tags are required because this how semantic-release figure out what commits were added to the repo since the last release.

I don't believe anyone is asking to use semantic-release without tags, but simply being able to choose when in the process of publishing and building we tag. I was hoping that I could use semantic-release for my project, but I can't figure out a way to get it to work. I need to:

1. generate a version number which is applied to an OpenAPI document (via a plugin)
2. run a code generator which produces a PR
3. merge PR, then tag a release on Github

Right now it seems I can't do this in this order - I can only tag my codebase immediately after updating the OpenAPI file, but before the relevant NPM package is generated.

[mattclough1]

Just want to +1 this. I really want to use this to bump a package.json version in a PR and then create a tag once that's merged.

[Jaesin]

I'm in the same position as a lot of the other folks in this thread. We have a multi-stage process that requires manual approvals but everything else is automated. A --skip-git-push or --skip-publish flag would be very useful.

[NexusNull]

I found an alternative that might suit your needs as well and wanted to share it with you.
https://juhani.gitlab.io/go-semrel-gitlab/
It can generate version numbers and is very simple to set up.

[soup-in-boots]

Honestly, I'm fine with the outcome of this conversation. I came here because I'm looking at creating pre-releases from mutliple, concurrently-existant feature branches, and I want to avoid creating git tags for the pre-release versions (as they would break when the feature branches are eventually rebased). I'm sure I can figure out a different way to handle my workflow such that I am not using semantic release, or else that I am not re-basing pre-release branches.

With all of that being said, I don't necessarily agree with this stance:

The tags are required because this how semantic-release figure out what commits were added to the repo since the last release. This is how we determine which commit to analyze and what the next version is going to be.

semantic-release already depends on well-formed commit analysis to calculate the next version, and when it's done, it creates a well-formed commit with the newly calculated version.

My understanding is that, while tags certainly makes things a lot easier, they're not strictly required for semantic-release to identify the prior version. Why not make tagging the default behavior, but provide a method that analyzes previous commits as a fallback method? I would imagine that tagging could then be made optional.

[s-gbz]

I've stumbled upon this issue whilst searching for this one:
#1647

Perhaps I can save someone some time as well.

tl;dr:

Create two CI stages

• One should be executed with dry-run to increment the version without pushing the changes to the repo
• (then comes your build where the version is used)
• Finally run semantic-release again to release the tag, changelog etc.

[zachspar]

You can use this plugin that sets GitHub Action output variables to be consumed in later steps or jobs. Will still output if you use dryRun: true