mirror of
https://github.com/windmill-labs/windmill.git
synced 2026-08-18 16:02:10 +00:00
Ruben Fiszel
65db58bfda
* 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>
Red Hat Linux Binaries
This directory contains the Dockerfiles for building Windmill binaries for Red Hat Linux 9.
We build Windmill on the Red Hat Universal Base Image 9. Windmill requires the xmlsec1-devel package which is not available in the default UBI9 repositories. It is however included in the CodeReady Builder for RHEL9 repository which requires a RedHat subscription.
Once the image is built, you can simply copy the binary on any Red Hat Linux 9 machine and run it. You will just need to install the xmlsec1 package which can be installed directly using yum/dnf install xmlsec1.
Notes
- you will need to register on Red Hat and have an individual developer subscription and pass the username and password to docker build:
docker build \ -f docker/RHEL9/Dockerfile \ --build-arg features="$features" \ --secret id=rh_username,src=/path/to/rh_username \ --secret id=rh_password,src=/path/to/rh_password \ .