Release workflow for shp CLI

[adambkaplan]

Changes

• Use gorelease to create binaries for windows, linux, and macOS on
  amd64 and arm64.
• Run workflow whenever a semantic version tag is created.

Fixes #21

/kind cleanup

Submitter Checklist

• Includes tests if functionality changed/was added
• Includes docs if changes are user-facing
• Set a kind label on this PR
• Release notes block has been filled in, or marked NONE

See the contributor guide
for details on coding conventions, github and prow interactions, and the code review process.

Release Notes

NONE

[adambkaplan]

/assign @SaschaSchwarze0

/cc @akram @otaviof

[openshift-ci]

@adambkaplan: GitHub didn't allow me to request PR reviews from the following users: akram.

Note that only shipwright-io members and repo collaborators can review this PR, and authors cannot review their own PRs.

In response to this:

/assign @SaschaSchwarze0

/cc @akram @otaviof

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[adambkaplan]

Example of how this will work (note that I will likely take this "release" link down once this PR merges):

https://github.com/adambkaplan/shipwright-cli/releases/tag/v0.0.1

To accomplish this all I had to was push a tag with a semantic version. As a follow-ups we can configure a workflow task that creates a semantic version tag, use the same/similar release notes generator as we do in shipwright-io/build, and so forth. I'd argue that this at least gets us to "minimum viable product."

[gabemontero]

Example of how this will work (note that I will likely take this "release" link down once this PR merges):

https://github.com/adambkaplan/shipwright-cli/releases/tag/v0.0.1

To accomplish this all I had to was push a tag with a semantic version. As a follow-ups we can configure a workflow task that creates a semantic version tag, use the same/similar release notes generator as we do in shipwright-io/build, and so forth. I'd argue that this at least gets us to "minimum viable product."

cool / looks good... eventually I think we'll want to port https://github.com/shipwright-io/build/blob/main/.github/workflows/release.yaml#L22-L31 over here and leverage the release note plugin, but as this is our first release, and we are already past our target for that, let's do it in a follow up item

[SaschaSchwarze0]

/approve

[SaschaSchwarze0]

Just noticed that the binary name in the package is not correct.

[adambkaplan]

@SaschaSchwarze0 @HeavyWombat incorporated your feedback & squashed commits.

[SaschaSchwarze0]

/lgtm
/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: SaschaSchwarze0

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [SaschaSchwarze0]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment