4 Commits

Include renames

Author	SHA1	Message	Date
jcoffey-dev	4b85113262	Publish: accept tags on release/* branches for hotfix releases ... The publish workflow only built a tag whose commit is on main. That keeps every image tied to reviewed code, but it means production can only get a fix together with everything that has landed on main since its release. A tag on a release/* branch is now accepted too. A hotfix branch starts at an earlier release tag, takes fixes through pull requests into it (so the code is still reviewed and CI-tested before it is tagged), bumps brand_version! and is tagged there. The tag must still equal v<brand_version!>, and the step prints which branch it was found on. A tag runs the workflow file from its own commit, so a hotfix branch that starts before this change needs this commit cherry-picked onto it before its tag is pushed.	2026-09-24 18:31:24 -07:00
jcoffey-dev	22d8ad8572	Publish amd64 first, then arm64, on a builder that keeps its cache ... Two release builds side by side on one machine each take twice as long, and production only needs amd64. publish-amd64 now pushes :<version> as soon as the amd64 build is done; publish-arm64 builds arm64 afterwards, then replaces :<version> with the two-platform index and moves :latest. Both jobs use one named BuildKit builder whose container outlives the job, so the dependency layer (cargo chef cook) is reused until the dependencies change. The release is created after amd64; the binaries are attached once arm64 is in.	2026-09-24 08:04:53 -07:00
jcoffey-dev	674ae5d037	Attach binaries to a release, for installs that are not containers ... A release published an image and nothing else, so there was nothing for a host install to download -- the only way to get the binary was to pull the image and copy it out, which makes "install without Docker" depend on Docker. Each release now carries inbuxa-linux-amd64.tar.gz, inbuxa-linux-arm64.tar.gz and SHA256SUMS, named as stalwart-migrator's are. They are taken out of the image this pipeline just pushed rather than compiled again. A second Rust build per architecture is the slowest thing here, and it would leave two artifacts that are meant to be the same build and only probably are. Extracting makes that identity a fact: the binary in the tarball is the file the image runs. `docker create` starts nothing, so copying a file out of an arm64 image on an amd64 runner needs no emulation. One thing the extraction cannot carry: the image grants the binary cap_net_bind_service, and a tar archive does not keep that xattr. The release body says so, and says what to do instead -- setcap, or AmbientCapabilities in the unit -- because a server that cannot bind 25 and does not say why is a bad first hour. Checked by hand against v2026.9.23 before this landed: both architectures extract to the right ELF, and the amd64 binary runs on a bare Debian 13 with every library resolved and reports its own version.	2026-09-22 19:31:05 -07:00
jcoffey-dev	8846a280f1	ci: publish the image on tags, port the weekly release ... publish.yml replaces .github/workflows/publish.yml: on a v* tag it checks the tag equals v<brand_version!> and is on main, builds the linux/amd64+arm64 image in one buildx run (the Dockerfile already cross-compiles, so only its final stage goes through QEMU), pushes :<version> and :latest to the registry, links the package, and creates the tag's release if it has none. weekly-release.yml ports .github/workflows/release.yml: bump brand_version! through the contents API, then create the release and so the tag, which starts publish.yml. It only dry-runs until RELEASE_LIVE=1 and a RELEASE_TOKEN secret exist.	2026-09-22 09:56:32 -07:00