Files
improvise/dist-workspace.toml
T
Edward Langley 90ccfb0154 feat: attach the assembled site to every release, and let the page name its build
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
2026-09-21 22:37:05 -07:00

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"]