Improve release action

[EdJoPaTo]

• include completions in release binary
• create binary for raspberry pi zero / 1
• create binary for M1 / arm64 macOS
• always build and only release on tags. All commits and PRs are also tested this way to ensure builds are working for the various platforms.
• Artifacts are always created which is helpful for testing branches and not yet released versions.

Minor Improvements:

• Dont define targets twice in matrix. This is less error prone
• generate version via git describe. This also includes versions in between releases (in artifacts).
• use-cross is done via function and not hardcoded
• GitHub Releases are done at the end of each job which simplifies the logic.
• dont use --color=always as actions-rs/cargo provides better GitHub integrations without the colors enabled.

This is heavily inspired by the workflows I use in my projects: My template, Example.
cargo fmt, cargo clippy and cargo test are also included in my workflows but they seem to be included in the ci.yml one which is a bit obscure to me currently.

[ajeetdsouza]

dont use --color=always as actions-rs/cargo provides better GitHub integrations without the colors enabled.

What exactly breaks when using --color=always? We should create an issue on their tracker regarding this.

cargo fmt, cargo clippy and cargo test are also included in my workflows but they seem to be included in the ci.yml one which is a bit obscure to me currently.

I'd be happy to clarify any doubts you have.

CI on macOS and Linux is done using a package manager called Nix, which specializes in reproducible builds. I specify all the CI logic in an xtask. Due to this, I'm able to run CI locally using the exact same environment as GitHub Actions, and if it succeeds locally, it succeeds on the server as well.

[EdJoPaTo]

dont use --color=always as actions-rs/cargo provides better GitHub integrations without the colors enabled.

What exactly breaks when using --color=always? We should create an issue on their tracker regarding this.

Without the colors the Hints where exactly some errors happen aren't there. Warnings might not be caught and get lost from the GitHub Interface. But you have a good point there: Analyze it more in depth and create an issue about it.

cargo fmt, cargo clippy and cargo test are also included in my workflows but they seem to be included in the ci.yml one which is a bit obscure to me currently.

I'd be happy to clarify any doubts you have.

CI on macOS and Linux is done using a package manager called Nix, which specializes in reproducible builds. I specify all the CI logic in an xtask. Due to this, I'm able to run CI locally using the exact same environment as GitHub Actions, and if it succeeds locally, it succeeds on the server as well.

My main hope would be that lock files and cargo test / clippy should work the same on different locations (locally / GHA). But I definitely support the "what runs locally has to run the same on CI and the other way around" way of doing it!

[ajeetdsouza]

@EdJoPaTo I made a few changes, in case you'd like to review them.

[EdJoPaTo]

Thanks for allowing me to review your changes! I adopted some of them for myself: EdJoPaTo/rust-binary-metafile-template@e5abad2

[ajeetdsouza]

Thanks for this PR @EdJoPaTo, this is really great!