Publish binaries

[mkroening]

Not having to build uhyve in our other project's CI should speed them up.

[n0toose]

Is this issue still a problem? (I presume yes.)

If so, I presume that #271 is a dependency and should be done first?

[n0toose]

There are a few things that could be done here, which are in- and out-of-scope?

• Build debug binaries on each push/commit, which may be useful for debugging if an integration test fails.
  • Could be integrated with https://nightly.link/, but creates a bigger dependency on GitHub.
• Build release binaries using GitHub Actions and publish them on the creation of a new tag.

[mkroening]

If so, I presume that #271 is a dependency and should be done first?

I would not say so. (But I also don't think we should containerize the CI. That's not a good fit for GitHub Actions in my opinion.)

• Build debug binaries on each push/commit, which may be useful for debugging if an integration test fails.

  • Could be integrated with https://nightly.link/, but creates a bigger dependency on GitHub.

• Build release binaries using GitHub Actions and publish them on the creation of a new tag.

I think we don't win much from nightly builds, so I'd say release binaries on tags would be good. I have done something similar for a private project: https://github.com/mkroening/edu-sync/blob/main/.github/workflows/release.yml

[mkroening]

Is this issue still a problem? (I presume yes.)

Now that I think about it: Not really. We only install Uhyve on our private KVM runners, which skip installation if already present, so there is not much to win here.

So this issue would be nice to have, but we don't win much either.