Build release artifact

[auxesis]

Run the Docker image with:

docker run cipherstash/proxy:latest

Details:

• Add a GitHub Actions workflow for building and publishing releasable artifacts
• Add mise tasks for building a binary and a Docker image, that can be run locally and in CI
• Add mise tasks for publishing the Docker image to Docker Hub, that can be run locally and in CI
• Use the new GitHub Actions linux/arm64 runners
• Runs on every push/merge to main
• Docker image is only available for linux/arm64 for now

[auxesis]

Next steps:

• User documentation for how to run and configure the container
• Build a multi-platform container image per this guide and @tobyhede's prior art
• Add workflow triggers:
  • A release is created
  • A manual invocation
• Upload the binary artifact to the release
• Add a cask for cipherstash-proxy to cipherstash/homebrew-tap so people can install with brew install cipherstash/tap/cipherstash-proxy
• Automatically signing the binary artifact so it runs without warnings on macOS

[CDThomas]

What's the reason for COPYing the binary here vs building the binary in the Dockerfile? Is the intent to not duplicate work and speed up builds since we also want to upload the binary as an artifact for GitHub releases?

[auxesis]

Is the intent to not duplicate work and speed up builds since we also want to upload the binary as an artifact for GitHub releases?

That's correct.

We have a hot cache in CI, but a cold one in Docker, so building in CI is faster.

That said, that advantage will disappear soon, as we'll need to disable caching on this workflow once we're building production releases, due to build cache poisoning.

[CDThomas]

Does this mean that the latest image will automatically be built/pushed on every merge to main? Is the intent here to help us iterate quickly to start (and then switch to something like only publishing latest on GitHub release later + also tagging with a version number)?

[auxesis]

Does this mean that the latest image will automatically be built/pushed on every merge to main?

Correct.

The intention is to get releases built and published as quickly as possible, so we can identify usability issues ASAP.

Later I will put up a PR to cut named/tagged releases.