CI CD improvement: set CI CD process, support versioning (WIP)

[Avivbens]

Hi 👋

Really nice tool! 🎉

The Reason behind

Here are some improvements that might get this project a bit more mature, in terms of versioning and deployment.
My goal is to allow users to install this tool within a CLI command, without the need to download via GitHub assets, as well as to be able to get version updates on the fly.

Example of the end goal

See my other tool for reference

[Avivbens]

Note

This is still WIP - we need to be able to run the workflows and understand what needs to be fixed.

The release step under .github/workflows/release.yaml should contain the output of the previous step - see the comment there. All assets should be declared by the .releaserc file.

[ozkatz]

Hey @Avivbens - can you provide more context as to what functionality this enables? Specifically, what does the following mean?

allow users to install this tool within a CLI command

Downloading Go binaries is indeed not the optimal way - perhaps we can consider other alternatives. The ones I'm familiar with are:

1. distribution through package management tools (brew, nix, apt, etc). This is what most mature tools do, as it also provides an upgrade path for users.
2. curl-pipe-shell, which isn't always the most secure, but is easy regardless of OS, unless Windows.
3. Sometimes, direct downloads do the trick (it is a single, statically compiled binary after all)
4. I assume this PR introduces a way different from the 3 listed above, happy to learn more about it.

Additionally, if we can find a way to avoid adding 8,000 lines of Node package metadata (and ideally, node, in general) - that would be preferred.

[Avivbens]

Hey @Avivbens - can you provide more context as to what functionality this enables? Specifically, what does the following mean?

allow users to install this tool within a CLI command

Downloading Go binaries is indeed not the optimal way - perhaps we can consider other alternatives. The ones I'm familiar with are:

1. distribution through package management tools (brew, nix, apt, etc). This is what most mature tools do, as it also provides an upgrade path for users.
2. curl-pipe-shell, which isn't always the most secure, but is easy regardless of OS, unless Windows.
3. Sometimes, direct downloads do the trick (it is a single, statically compiled binary after all)
4. I assume this PR introduces a way different from the 3 listed above, happy to learn more about it.

Additionally, if we can find a way to avoid adding 8,000 lines of Node package metadata (and ideally, node, in general) - that would be preferred.

Sure thing! 👍

Here is a short explanation of what I think might be just as good as needed:

Q1

I think we need to use brew here (or apt for Linux users). It is much more mature.
For that, we still need some version management, which would be acquired by this PR in the future. In this way, we would be able to push new versions via the package managers described above 🎉

Q2

For my own tool, I use curl-pipe-shell due to the understanding that it should be installed even before brew - this is the idea of it. It should set up your machine without any additional stuff needed (under the hood would also install brew).

For cz - no need for such a thing.

Q3

It could be, but probably a lot easier to allow pushing releases by the CI / CD, and allow brew or any other package manager to grab the suitable binary by the machine type.

Q4

Well, I see your point. We can come up with some alternatives, but as far as I know - NodeJS for CI / CD is so easier than any alternative. GitHub itself provides some native features only with JS. This is not a production code, but just some dev tools, so I think it is just fine to use them (semantic-release is super handy from my experience)

[Avivbens]

LMK how can I change things so it'll fit into your vision 🎉