90ccfb0154
improvise-oujb. A tagged release carried four native tarballs and nothing for the web; the site shipped only by ci.yml's pages-deploy, on a push to main. Pages keeps tracking main (user, 2026-09-22: "I like Pages showing the latest main for now"), so this is a CAPTURE, not a second deployment: the tarball is a self-hostable copy of the site as of the tag and a rollback target, not what a visitor to the published site is running. pages-deploy is untouched. Mechanism is dist's own [[dist.extra-artifacts]], so it survives `dist init`: `dist plan` under the pinned 0.30.4 lists improvise-web.tar.gz beside the four platform tarballs and `dist generate` leaves release.yml byte-identical. The build command is scripts/build-web-release.sh, which calls web/build.sh and web/assemble.sh -- the same two scripts ci.yml and a developer run, so there is no second way to build the bundle. Its toolchain pins come from scripts/web-toolchain-versions.env, which ci.yml's build job now reads too. `github-build-setup` was measured and does NOT help: it injects into build-local-artifacts only, which is the wrong job for a global artifact. The page now names the build it was assembled from in #build-version, stamped by web/assemble.sh with the same token as the bundles and verified by the same scripts/assemble-stamp.sh gate. An unassembled tree honestly reads "unstamped". Verified by running `dist build --artifacts=global` locally: the script ran, the site assembled, and dist placed improvise-web.tar.gz in target/distrib. Not verified: a real tag push, which would require cutting a tag. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FC2jVn8Au7E9JPkw6bwXXH
40 lines
1.7 KiB
TOML
40 lines
1.7 KiB
TOML
[workspace]
|
|
members = ["cargo:."]
|
|
|
|
# Config for 'dist'
|
|
[dist]
|
|
# The preferred dist version to use in CI (Cargo.toml SemVer syntax)
|
|
cargo-dist-version = "0.30.4"
|
|
# CI backends to support
|
|
ci = "github"
|
|
# The installers to generate for each app
|
|
installers = ["shell"]
|
|
# Target platforms to build apps for (Rust target-triple syntax)
|
|
targets = ["aarch64-apple-darwin", "aarch64-unknown-linux-gnu", "x86_64-apple-darwin", "x86_64-unknown-linux-gnu"]
|
|
# Path that installers should place binaries in
|
|
install-path = "CARGO_HOME"
|
|
# Whether to install an updater program
|
|
install-updater = false
|
|
|
|
# The assembled web site, attached to every release (improvise-oujb).
|
|
#
|
|
# THIS IS DIST'S OWN MECHANISM AND MUST STAY THAT WAY. `.github/workflows/
|
|
# release.yml` is autogenerated and says so on line 1; a hand edit is silently
|
|
# clobbered by the next `dist init`. Verified against dist 0.30.4, the version
|
|
# pinned above: `dist plan` lists improvise-web.tar.gz beside the four platform
|
|
# tarballs, and `dist generate` leaves release.yml byte-identical -- so there is
|
|
# nothing in the workflow for a regeneration to lose.
|
|
#
|
|
# NEXT `dist init`: keep this block. It is not generated, and `init` will not
|
|
# put it back if you drop it.
|
|
#
|
|
# The build command runs in `build-global-artifacts`, which carries a Rust
|
|
# toolchain and nothing else. `github-build-setup` does NOT help here -- it was
|
|
# measured, and it injects into `build-local-artifacts` only, which is the wrong
|
|
# job for a global artifact -- so the script provisions its own pinned wasm-pack
|
|
# and node. It builds nothing of its own: it calls web/build.sh and
|
|
# web/assemble.sh, the same two scripts ci.yml and a developer run.
|
|
[[dist.extra-artifacts]]
|
|
artifacts = ["improvise-web.tar.gz"]
|
|
build = ["sh", "scripts/build-web-release.sh"]
|