Add config to skip git push

[bouchardm]

This MR allow someone to skip the git push to the remote repository with a config.

By default the push stay enable.

Why ? Someone running semantic-release in a monorepo could need to do a release on every affected package and after that do the push manually. Without this option semantic-release/git work on the first release but break on every subsequent release because git isnt up to date with master.

Feel free to reach out if you need anything done to get the MR merged !

<3

[travi]

Why ? Someone running semantic-release in a monorepo could need to do a release on every affected package and after that do the push manually.

monorepos are not officially supported by semantic-release, and this complexity is one of the reasons why. semantic-release is designed to coordinate the complete release process for individual packages. deferring part of the process to then require a manual step afterward is not in line with the goals of the project.

instead, i would encourage you to strongly consider whether you actually need to push anything back to git as a result of the release process. our normal recommendation is to avoid the git plugin unless you absolutely need it. tags are used to track the previous version. you can use github releases (or similar) instead of a changelog file. can you avoid the problem you describe by avoiding committing details like these?

[seebeen]

To expand on answer @travi gave. The whole idea is that the release process is automatic. You push the code changes with the commit type and scope, and semantic-release does all the rest. That's the reason version in the repo stays on 0.0.0-development. The next version is determined by your commits and the previous tags.

Doing something manually in-between just adds the human factor back in, which runs against everything semantic-release does.

[bouchardm]

I understand your point.

monorepos are not officially supported by semantic-release

I'm not asking for support of monorepos, but with this option, it is at least possible :)

this complexity is one of the reasons why. semantic-release is designed to coordinate the complete release process for individual packages

Doing something manually in-between just adds the human factor back in, which runs against everything semantic-release does

I understand that; that's why by default, it stays simple. I feel like an opt-in option to allow a bit more control could be useful for situations like these. In my opinion, this is the simplest change needed to start gracefully handling multi-package repositories.

can you avoid the problem you describe by avoiding committing details like these

No, for auditing reasons, we need everything in the code.

With this setup, I was able to make semantic-release work with a monorepo made with nx. The only step required was to do a single push after running semantic-release on every affected package.

I don't want to make your project less fully automated, just more customizable for power users :)

I'm happy to elaborate on anything if you need!

[seebeen]

May I ask - is it completely necessary to have different version per package in a monorepo? :)

[travi]

is it completely necessary to have different version per package in a monorepo?

i would pretty strongly argue that this is the most correct way to handle a monorepo with regard to semver in general. semver is intended to communicate to consumers of a package what the impact would be of accepting the changes into their project. if the version communicates something that isnt related to the changes for that specific package, it fails to communicate the impact properly. syncing versions within a monorepo violates that goal and likely highlights a lack of isolation between packages.

[travi]

I understand your point.

respectfully, there is more to it than the understanding you are conveying when influenced by your goal.

I'm not asking for support of monorepos

what you are asking for is the addition of an option that would only exist in order to support monorepos. there is no other reason for that option to exist with our currently supported workflows. in addition, as explained above, it takes a step away from semantic-release's core goal of automating the complete release workflow.

we have to be careful about the amount of configuration that we accept into the project because it is very difficult to remove an option once it has been added. once added, that is additional complexity in the logic that we need to maintain for the life of the project. we risk breaking it in this case, because it is for supporting a use case that is not officially supported and less likely to be used for maintainers, so regressions are more likely to make their way in. in addition, more options means more ways for users to misconfigure something and then open support requests about why things are working how they want. our small team is already overloaded and we simply cannot justify this sort of option for an unsupported workflow.

No, for auditing reasons, we need everything in the code.

at least in the case of github releases, i would argue that the release notes are still leveraging the capabilities of git to relate the notes to the code since the releases are tied to the git tag that is used for identifying where the release happened in the history of the repo. i cannot imagine an auditing team that would not accept that for whatever evidence needs to be provided for auditing purposes. i can imagine that some auditing teams might need some explanation to understand the details, though. in the end, you and your team need to make the decision for what works for your goals, but this detail feels solvable to me.

With this setup, I was able to make semantic-release work with a monorepo made with nx. The only step required was to do a single push after running semantic-release on every affected package.

we do really appreciate you sharing your solution and proposing this change. unfortunately in this case, it isnt a good fit for the goals of the project. you are certainly welcome to maintain your own fork if you wish, so that you can continue to enable this approach for your team, but we won't be accepting this change at this time.

i wont say that we will never support monorepos in semantic-release, but the reality remains that we do not currently. if we do choose to pursue such support at some point in the future, we would only approach support that would consider details like this in ways that were automatically handled as part of the release workflow without requiring more knobs to turn to get things right.

in the future, please feel free to open an issue asking us if we would be open to contributions like this before investing the effort into a working PR. we definitely value you sharing your solution, but we also dont want to cost you the effort of getting to a fully working solution before hearing that it doesnt align with project goals.