Add binaries to every new release

[thepetk]

What does this PR do?

Introduces the release.yaml workflow which will add 5 binaries into an existing release. Those will be:

goosarch:
  - 'darwin/amd64'
  - 'linux/amd64'
  - 'linux/ppc64le'
  - 'linux/s390x'
  - 'windows/amd64'

The flow of a release would require a user to push a tag in order to trigger this workflow. As a result those 5 binaries will be added to the tag.

Our release process remains the same:

• Create a new release with a new tag.
• The tag has to start with "v" in order to trigger the binary creation job.
• [Optional] Autogenerate the release notes
• Creating the release with a new "v" tag triggers the release.yaml
• The binaries are added to the new tag and they are reachable through the new release.

Which issue(s) does this PR fix

fixes #40

PR acceptance criteria

Testing and documentation do not need to be complete in order for this PR to be approved. We just need to ensure tracking issues are opened.

• Unit/Functional tests

• Documentation

How to test changes / Special notes to the reviewer

A test run for this flow has already tested here: https://github.com/thepetk/alizer/releases/tag/v1.0.0

[mike-hoang]

Overall, the workflow works and looks ok but I'm wondering if this is the right approach? Compared to odo, they push all their images to a mirror after signing and verifying: https://developers.redhat.com/content-gateway/rest/mirror/pub/openshift-v4/clients/odo/

Currently the binary for macOS isn't signed so we get the "cannot be verified error" which is a little annoying to have to go into settings every time to disable

➜  Downloads codesign -dv --verbose=4 odo-darwin-amd64
...
Authority=Developer ID Application: Red Hat, Inc. (HYSCB8KRL2)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=May 31, 2023 at 5:09:54 AM

➜  Downloads codesign -dv --verbose=4 alizer-darwin-amd64
alizer-darwin-amd64: code object is not signed at all

[elsony]

Currently the binary for macOS isn't signed so we get the "cannot be verified error" which is a little annoying to have to go into settings every time to disable

1. By using the github action, do we still have the issue mentioned earlier?
2. The binary gets created for each new release as part of this PR. However, where do we expose those release builds for download? Are we adding something to the readme so that the user knows that they can download those binaries?

[thepetk]

1. By using the github action, do we still have the issue mentioned earlier?

By using the github actions I'm not sure if we will be able to sign the binaries.

2. The binary gets created for each new release as part of this PR. However, where do we expose those release builds for download? Are we adding something to the readme so that the user knows that they can download those binaries?

The binary is added to each release tag. So they can be downloaded if someone accesses the release page. I could create a section in readme with instructions on how to download the binary

[thepetk]

I could create a section in readme with instructions on how to download the binary

@elsony and @mike-hoang I've added a small section in readme with instructions on how someone can download the binaries.

As mentioned above, for the signing I don't think there is a way to achieve this through public github-actions