| commit 506a2c5792ff841760b5b8c88fefdd8b370446e0 parent 4e8d25d449d5f22ec264209d9548a7d73d0933f2 Author: sqzer <110329244+sqzer-x@users.noreply.github.com> Date: Sat, 25 Jul 2026 22:55:25 +0900 Add a release workflow and an AUR PKGBUILD Tagging `v*` builds two targets and attaches them to the release: x86_64-unknown-linux-musl and aarch64-apple-darwin, each with a checksum beside it because otherwise nobody downloading has a way to check anything. The musl job is not only a build target. Whether this project can link statically against musl is what dictated its dependency choices — syntect is pinned to its pure-Rust regex engine specifically because the default is an Oniguruma C binding, and that binding is what breaks here. That reasoning has been written down since the beginning and never once executed. Now it runs on every release. Each job then runs the binary it produced: `init`, `build`, and a check that the page exists. A static build that links and dies at startup is a real failure mode, and "the compiler was happy" is not evidence that a binary works. The workflow also runs on workflow_dispatch, where it uploads artifacts and creates no release. Finding out whether a target builds should not require an irreversible act; tags are the only thing that publishes. fail-fast is off. If macOS breaks, the Linux archive is still worth having while the cause is found. The PKGBUILD builds from the tag tarball rather than shipping a binary. Building a Rust tool from source is normal on Arch, and two packages invite the question of which one is current. Its checksums are SKIP because they cannot be computed before a tag exists — packaging/aur/README.md gives the order to do it in, and says plainly that publishing needs an AUR account and an SSH key, which is not something to automate from here. Nothing is released yet. The docs say so rather than describing binaries that do not exist. Diffstat:
|
sqzass~ static site generator in Rust |
| git clone https://github.com/debuman/sqzass.git |