Set up workflows to add binaries for divviup-cli on github release
#492
Comments
jbr
changed the title
divviup-clidivviup-cli on github release
|
An important question here is where to store the binaries we build. I see two obvious options: We could attach them to the GitHub release. Per GH docs, "[t]here is no limit on the total size of a release, nor bandwidth usage", so attaching 4-6 ~12 MB binaries should be no problem. This seems fairly natural if we expect to direct potential adopters to our GitHub repos and have them work with the READMEs on We could also create a generic repository in Google Artifact Registry and upload binaries there. The downsides are that (1) this would cost us money and (2) it might not be quite as discoverable as storing them in GitHub, though in either case we could provide a link to the latest binary in a README. I lean toward using GitHub artifact storage, because it'll be less infra for us to set up and wrangle and it'll make the artifact build action simpler (no need to set up identity federation with GCP). |
Adds a simple `cli-release.yml` GitHub Actions workflow that just builds `divviup-cli` on Ubuntu, Windows and macOS runners. The goal here is just to get a basic workflow checked in and acknowledged by GitHub Actions so that I can then debug and iterate on it in a later PR. Part of #492
|
Binary builds inside GH release seem like the de-facto standard for software not present in package managers, so SGTM. |
Adds a simple `cli-release.yml` GitHub Actions workflow that just builds `divviup-cli` on Ubuntu, Windows and macOS runners. The goal here is just to get a basic workflow checked in and acknowledged by GitHub Actions so that I can then debug and iterate on it in a later PR. Part of #492
Builds `divviup-cli` for Windows, macOS and Linux, across x86_64 and aarch64. The resulting executables are attached to the release, as in https://github.com/divviup/divviup-api/releases/tag/0.3.7. Part of #492
Builds `divviup-cli` for Windows, macOS and Linux, across x86_64 and aarch64. The resulting executables are attached to the release, as in https://github.com/divviup/divviup-api/releases/tag/0.3.7. Part of #492
Builds `divviup-cli` for Windows, macOS and Linux, across x86_64 and aarch64. The resulting executables are attached to the release, as in https://github.com/divviup/divviup-api/releases/tag/0.3.7. Part of #492
|
On macOS, it may be possible for us to sign or notarize the binaries so that users don't have to click around quite so many warnings or strip quarantine On Windows, some (but not all!) of the binaries we build flagged Chrome and Edge's malware detection (in both cases, this may actually be Windows Defender). It might be possible for us to somehow bless our binaries with Microsoft to make them easier to download. In both cases, I'm not sure if there are automation-friendly solutions. |
So that subscribers can download a binary release instead of needing a Rust toolchain and needing to compile the binary.
I think these platforms are a good starting point:
Additional considerations:
The text was updated successfully, but these errors were encountered: