fix: run gettext after dialyzer so they stop sharing _build - #91
Merged
Merged
Conversation
`mix gettext.extract --check-up-to-date` force-recompiles the project so the gettext macros re-expand. A forced recompile empties `_build/dev/lib/bb_example_so101/ebin` and `.../consolidated` for a second or two before refilling them, and `ex_check` was running that tool alongside `mix dialyzer`. Elixir's build lock serialises the two compiles, but not dialyzer's beam reads, which happen after it releases the lock. When the wipe lands in that phase, dialyzer either fails to read a consolidated protocol beam or enumerates an empty ebin and halts with "No .beam files to analyze". Making `gettext` depend on `dialyzer` moves the forced recompile to the end of the run, when nothing else is reading the build directory.
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
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.
What
Make the
gettexttool in.check.exsdepend ondialyzeras well asex_unit, somix gettext.extractno longer runs alongsidemix dialyzer.Why
mix gettext.extract --check-up-to-datere-expands the gettext macros byforce-recompiling the project (
mix compile --force-elixir+mix compile.elixir --force). A forced recompile empties_build/dev/lib/bb_example_so101/ebinand.../consolidatedfor a second or twobefore refilling them, and
ex_checkwas running that tool in parallel withmix dialyzer.Elixir's build lock serialises the two compiles, but dialyzer reads beams after
it releases the lock — first when checking the PLT, then when it globs the ebin
to build its file list. If the wipe lands in either phase, dialyzer fails:
That is what failed the
bb_example_so101job in bb's Test Subprojectsworkflow on the
v0.30.1tag push (run 32619948357), and it is the same failuretracked in beam-bots/bb#245 for
bb_example_wx200. Those two are the onlypackages in the ecosystem with both
gettextanddialyxir, which is why onlythey are affected. bb's workflow deletes
_build/*/*.plt.hashbeforemix check, forcing dialyxir's full PLT re-check and widening the exposure fromsub-second to roughly twenty seconds — hence the failures show up there and
essentially never here.
Verification
The mechanism was diagnosed and reproduced in
bb_example_wx200(beam-bots/bb_example_wx200#97), where
mix gettext.extractoverlappingmix dialyzerreproduces the error above byte for byte, and the same one-linechange moves the forced recompile to after dialyzer finishes. This repo has an
identical tool set and
.check.exs; the change here has not been run through alocal
mix checkof its own.The
deps: [:ex_unit, :dialyzer]restates:ex_unitbecauseex_checkreplacesthe option rather than merging it.