Repository navigation
ci: publish standalone Linux binaries with GitHub releases - #112
Conversation
|
All contributors have signed the CLA. ✅ |
|
I have read the CLA Document and I hereby sign the CLA |
shockalotti
left a comment
There was a problem hiding this comment.
Reviewed the diff — build correctness checks out (pure-Go sqlite, CGO_ENABLED=0 already in the builder, tzdata embedded, scratch-stage layout matches the tar paths, checksums attached, release gating correct, Dockerfile default target unaffected, docs accurate including the Litestream caveat).
Not merging yet for one reason: this is still a draft, and the entire new chain (export/package/upload/download/release) has never executed green anywhere — the fork workflow runs sit at action_required. Before merge: approve the fork workflows to run (or push to a non-fork branch) so Docker publish goes green on the PR, and dry-run the release job's download + create step somehow, since that line can never run on a PR by construction.
Optional efficiency nit: gate the export/package/upload steps to tags so every PR/main/dev build doesn't pay multi-arch packaging cost for artifacts only releases consume.
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
- Standalone export target — adds a
scratchstage toDockerfilethat exports the builder'scalnodebinary (embedded frontend included) plusLICENSEfor both architectures. - Binary export and packaging — a second buildx build uses
type=local,platform-split=true, then tars eachlinux_*directory intocalnode_<version>_<os>_<arch>.tar.gz, writeschecksums.txt, and uploads the directory as an artifact. - Release attachment — the release job downloads the artifact into
dist/releaseand passes the archives plus checksums togh release create. - Docs — README links to a new DEPLOY.md standalone-binary section covering checksum verification, secrets, proxy/Host and CA requirements, and the Litestream/entrypoint caveat.
The mechanics line up with the surrounding pipeline: semver tags resolve steps.meta.outputs.version to a v-less x.y.z matching the documented archive names, buildx's platform-split output names match the linux_* glob, and time/tzdata is imported in cmd/calnode/main.go, so the "timezone database embedded" claim holds. No blocking or non-blocking correctness issues found.
deepseek-v4.1-flash | 𝕏
|
Landed as #223 (merged), so nothing for you to do here. Recording the reasoning while it is fresh. The one follow-up: your export, packaging and upload steps were all ungated, so every PR and branch push packaged and stored an archive that only the tag-triggered release job ever downloads. #223 gates only the upload, and the condition deliberately mirrors the release job rather than a bare tag check: if: startsWith(github.ref, refs/tags/v) || (github.event_name == "workflow_dispatch" && inputs.dry_run)A plain Export and packaging stay ungated on purpose: they are what proves the Verified both directions: on a PR, export and packaging pass and upload is skipped; on a Thanks for this one. The static binary was a good call: the embedded UI plus |
Since Calnode#112 the build job exports and packages the standalone binaries on every run, then uploads them as an artifact. Only the release job consumes that artifact, and it runs on a version tag or a dry-run dispatch, so every PR and branch push currently stores an archive nobody downloads. Gate just the upload. Export and packaging stay ungated on purpose: they are what proves the `standalone` stage still builds, and moving that check to release time is exactly the trap of a gate that cannot fail until it matters. The condition deliberately mirrors the release job's, including the workflow_dispatch dry run. A bare `startsWith(github.ref, 'refs/tags/v')` would make the dry-run rehearsal fail at download-artifact, which is the one path that exists to prove the release sequence works without cutting a tag.

Publish Linux amd64 and arm64 archives, including the license and SHA-256 checksums, with future tagged releases. This reuses the existing Docker build and adds standalone setup instructions, including the difference in Litestream backup behavior.
Following up on #108: I created nibrun to make open-source apps that ship as a single binary easy to deploy. Official release assets will let me finish Calnode’s one-click preset and app page, then propose a “Deploy on nibrun” button like PicoShare’s.
Validated with
go test ./...,make build, andactionlint. Built and packaged both architectures, verified checksums, and ran each extracted binary under a 256 MB limit: health/readiness, database migrations, version metadata, embedded admin UI assets, and restart all passed.