Open inahga opened 1 year ago
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 divviup/divviup-api
; they won't have to go too far to find links to the binaries.
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).
Binary builds inside GH release seem like the de-facto standard for software not present in package managers, so SGTM.
divviup-api
GitHub releases will now include binaries for (Windows, macOS, Linux) x (aarch64, x86_64). We shouldn't quite close this, though, because there's further work here.
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 xattr
s when they download binaries.
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: