Ensure Release Assets

[hh]

@ii generates assets for our tags here:
https://github.com/ii/wgtunnel/releases/tag/v0.1.0

Having trouble generating them here:
https://github.com/cloudnative-coop/wgtunnel/actions/runs/4716351905

Help wanted!

[hh]

@zachmandeville can you document where / how you created the tunnel release assets?

[zachmandeville]

For ii/wgtunnel, I manually created them using go build flags. I set the list of supported GOOS/GOARCH combos and then ran go build for each pair.

The second part was uploading it up to the repo, which I did by doing a tag commit, which lets you upload assets for the tag. It was a blunt, manual approach.

It would be good to use the existing ci and make tools of this repo, but that is a bit more complicated. I looked into it today, to try to get ourbuild steps working, and the issue is how much coder/wgtunnel is used throughout the ci. The make file, for example, references the tags in https://github.com/coder/wgtunnel and the build steps themselves would pull from the same repo, until I updated the go.mod and go.sum. So I think the next stage of work would be to comb through the repo and update all references to this fork, but also ensure that the same infrastructure exists for this fork.

It is making me wonder if it would be more useful to be collaborating with the upstream coder team, instead of making a fork of this tool? Are we changing the feature-set of this tool a bunch, or just wanting to build it for multiple targets? If we are wanting to switch over everything to this fork, we'll now be maintaining the tool wgtunnel with the work that entails. I'd like to discuss the ultimate goal, to see if there's an easier way to get this done that invites cooperation across teams and people.

[hh]

Yes, we will be pushing this upstream.

[hh]

I have created a PR to review / merge and submit upstream.
@zachmandeville can you review with me today.

[hh]

Here is the PR I created to address this: https://github.com/coder/wgtunnel/pull/15/files

[zachmandeville]

I merged the tunnel binary branch into main so it would be easier to test our actions, and found that as long as we are following the versioning flow of coder, the action works and publishes all assets in a list.

You can see it now in our release page for v0.1.12

The main thing is that the releases action is expecting an annotated release tag, and this tag should follow semver.

If you are not pushing a release tag to main, then the. action won't fire. If you push a tag without annotation, then you will get an error from our scripts/version.sh file.

Pushing with an annotation will let version.sh do its job and the action shows all release assets by default.

Pushing an annotated release

This is straightforward in magit. spc gg to get to the magit screen, then t to create a tag. -a to annotate, and then press r to have it be a release tag. Magit will prompt for the release using semver automatically, then prompt for the annotation.