-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Add ability to disable automatic git tag/push #964
Comments
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 |
Duplicate of #944 |
Duplicate of #957 |
I'm aware that tags themselves are mandatory, but it is not mandatory for Moving update script to shell file and using 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). |
I don't know what Also the statement "as long as tags are there in the end" is incorrect as some
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. |
Yes, I meant
In that comment you only explain that
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 |
Once #563 is released, tags are created:
The correct determination of the last release for the Implement what you are requesting would:
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 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. |
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"
]
} |
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 This may differ subtly from what the original issue writer wanted, which seems more related to skipping 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 |
Could you work around by using a "local" on-disk "remote"? |
@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. |
@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. |
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. |
@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. |
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. |
I'm surprised to see this conversation was left this way. I see variations of this being repeated:
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
Right now it seems I can't do this in this order - I can only tag my codebase immediately after updating the |
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. |
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 |
I found an alternative that might suit your needs as well and wanted to share it with you. |
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:
My understanding is that, while tags certainly makes things a lot easier, they're not strictly required for |
I've stumbled upon this issue whilst searching for this one: Perhaps I can save someone some time as well. tl;dr: Create two CI stages
|
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 |
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.
The text was updated successfully, but these errors were encountered: