fix(mise): orchestrate elm builds serially to eliminate Windows race#1281
Merged
Conversation
When the elm package cache (~/.elm) or per-project elm-stuff/ is cold, multiple concurrent `elm make` invocations race on ~/.elm/<package>/artifacts.dat and the shared elm-stuff/ files, producing the "PROBLEM BUILDING DEPENDENCIES" failure that's been intermittently breaking the Windows CI build (e.g. PR #1280's 26558683076 and 26559185295 runs). Linux mostly avoids it thanks to friendlier file-locking semantics but the underlying race is the same. The previous round of fixes added `//MISE depends=` headers expecting mise to serialize tasks. mise reads those headers but its scheduler parallelizes any tasks whose deps are satisfied — both Linux and Windows CI logs show cli, cli2, dev-server, try-morphir, and treeview starting within ~1ms of each other after check-elm-docs finishes. The recent passing runs were the race coming out the other way, not a real fix. Changes: - .mise/tasks/build.ts: drive the elm-touching tasks via an explicit `mise run --skip-deps <task>` chain (check-elm-docs → cli → cli2 → dev-server → try-morphir → components → morphir-ts). --skip-deps stops each subtask from re-running its own declared deps. treeview (webpack only) runs in parallel alongside the chain. - .mise/tasks/build/dev-server.ts: serialize its three internal elm makes — they all target cli/elm.json, so the same race that motivated the build:cli serialization applies to them. morphir-ts is in the elm chain because it invokes elm indirectly via node-elm-compiler in cli/morphir-elm.js (visible as "Compiled in DEV mode" in its output). Verified locally on Windows with a cold elm-stuff: full build completes successfully.
Add `//MISE sources=[...]` / `outputs=[...]` to every build subtask so mise can skip a task whose inputs haven't changed. The orchestration in build.ts already invokes each subtask via `mise run --skip-deps`, so the freshness check kicks in on every step independently. Cold rebuild from a clean tree still does the full work serially. Warm rebuild with no source changes finishes in seconds (mise reports "sources up-to-date, skipping" for each elm task). Touching a single .elm file rebuilds only the affected tasks — for example, touching cli/src/Morphir/Web/TryMorphir.elm reruns cli, dev-server, try-morphir, components, and morphir-ts but leaves check-elm-docs, cli2, and treeview skipped. Notes: - Patterns are deliberately broad (`src/**/*.elm`, `cli/src/**/*.elm`) rather than module-precise. elm tracks transitive imports itself, so conservative globs trade a few extra rebuilds for safety. - build:components has no sources/outputs because its output overlaps its input (concat insight.js + morphir-insight-element.js → insight.js), which would make mtime-based freshness ambiguous. It's a fast concat and always re-runs. - Removed the Promise.all that ran build:treeview alongside the elm chain — the speedup was marginal and the fully serial form is easier to reason about now that each subtask gets independent freshness caching.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Follow-up to #1280. The Windows build is intermittently failing with
-- PROBLEM BUILDING DEPENDENCIES --onelm/html 1.0.0(e.g. PR #1280 run 26558683076, run 26559185295) becauseelm makeis not concurrent-write-safe: multiple processes race on~/.elm/<package>/artifacts.datand on the per-projectelm-stuff/. Linux mostly wins the race thanks to friendlier file-locking semantics, but the bug is the same on both platforms — the recent passing Windows runs were the race tipping the other way, not a real fix.The previous round of fixes added
//MISE depends=headers expecting mise to serialize. mise reads those headers but its scheduler parallelizes any tasks whose deps are satisfied — both Linux and Windows logs showbuild:cli,build:cli2,build:dev-server,build:try-morphir, andbuild:treeviewstarting within ~1 ms of each other oncebuild:check-elm-docsfinishes.Changes
mise run --skip-deps <task>chain:check-elm-docs → cli → cli2 → dev-server → try-morphir → components → morphir-ts.--skip-depsprevents each subtask from re-running its declared deps.build:treeview(webpack only) runs in parallel alongside the chain.elm makecalls; they all targetcli/elm.json, so the same race that motivated thebuild:cliserialization applies here.build:morphir-tsis in the elm chain because it invokes elm indirectly vianode-elm-compilerincli/morphir-elm.js(the "Compiled in DEV mode" output in its logs is from elm).Test plan
cli/elm-stuff/cli2/elm-stuff/elm-stuffubuntu-latestwindows-latest