Ruben Fiszel 65db58bfda fix(frontend): pin sveltekit version.name so builds are reproducible across architectures (#10315) ...

* fix(docker): pin frontend build stage to linux/amd64

Rollup selects platform-specific native binaries that can emit different
content-hashed chunk filenames for identical sources. The frontend assets are
embedded into the Rust binary via rust_embed, so building the stage once per
target architecture produced amd64 and arm64 images whose HTML references
`_app/immutable/chunks/<hash>.js` files that only exist in that architecture's
image. In a mixed-architecture cluster, a page served by a pod of one arch 404s
on JS/CSS fetched from a pod of the other.

Pinning the stage makes both image variants embed byte-identical assets. The
stage output is JS/CSS/HTML/WASM only, so the build platform does not leak into
the artifacts.

Fixes WIN-2242

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* docs: tighten frontend platform-pin comment

Vite 8 bundles with rolldown, not rollup; name the right bindings and keep the
constraint to four lines.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(frontend): make the build reproducible so mixed-arch clusters agree on asset names

SvelteKit defaults `kit.version.name` to `Date.now().toString()`, so every build
of the same commit gets a different version string. It is embedded in the client
chunk (and in the `__sveltekit_<hash>` global derived from it), which changes
that chunk's content hash and cascades into new filenames for roughly a quarter
of `_app/immutable`. The assets are baked into the binary via rust_embed, so the
amd64 and arm64 images of one release ship different `chunks/<hash>.js` names:
in a mixed-architecture cluster, HTML served by a pod of one architecture 404s
on assets requested from a pod of the other.

Measured on the published windmill:1.770.0 images: 224 of 863 asset filenames
differ between the two architecture variants, yet 854 of 855 chunks are
byte-identical once chunk-name references are normalized. The single genuinely
differing chunk is the one carrying the timestamp. The bundler is deterministic
across architectures; the timestamp is the whole divergence.

Pinning the version to the package version (overridable via WM_BUILD_VERSION)
makes repeat builds byte-identical. `version.pollInterval` is 0 and nothing
reads the `updated` store, so this has no runtime behavior change.

This supersedes pinning the Docker frontend stage to linux/amd64, which fixed
the symptom by building the stage under emulation on the arm64 builder — that
cost 32 minutes of QEMU time per build and left the underlying non-determinism
in place.

Fixes WIN-2242

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(frontend): key the sveltekit version on the commit sha

The package version only moves on releases, but `:dev` and RHEL images are
published on every main push. Two such deployments would then advertise the same
SvelteKit version, and SvelteKit only recovers from a chunk that 404s after a
redeploy (client.js: "Referenced node could have been removed due to redeploy")
when the deployed version differs from the baked-in one, so an open tab would
render an error page instead of reloading.

Pass the commit sha through WM_BUILD_VERSION from every workflow that builds the
root Dockerfile, so the value is identical across the per-architecture builds of
one commit and distinct between commits. The package version stays the fallback,
which keeps unwired builds architecture-consistent.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(docker): declare WM_BUILD_VERSION in the RHEL frontend stages

The RHEL workflows copy docker/RHEL{8,9}/Dockerfile over the root one before
building, so the build-arg was unconsumed there and those images fell back to
the package version: two RHEL builds between releases would share a SvelteKit
version across different manifests.

Also switch the root declaration to the `ARG name=""` form used by `features`.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* docs: keep the version-arg rationale in one place

The root Dockerfile comment restated what frontend/svelte.config.js already
documents; point at it instead, matching the RHEL Dockerfiles.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-07-24 23:55:47 +02:00

..

Dockerfile

fix(frontend): pin sveltekit version.name so builds are reproducible across architectures (#10315)

2026-07-24 23:55:47 +02:00