Docker: pin Julia to 1.10.11, unbreaking the image build - #1031
Closed
alongd wants to merge 1 commit into
Closed
Conversation
Every "Docker Image Build and Push" run on main since 20 Aug has died in the same
layer, `source install_rms.sh`, with
install_rms.sh: line 140: 77 Segmentation fault (core dumped) python <<EOF
That heredoc is the `from juliacall import Main` check. The builder asked juliaup
for the floating `1.10` channel, which resolved to 1.10.11 up to 16 Aug and to
1.10.12 from 17 Aug; juliacall segfaults on import under 1.10.12. RMG-Py hit the
same wall and pinned 1.10.11 in its own CI and Dockerfile in 62eb728c0.
pyjuliacall is deliberately left as it is: the identical Dockerfile with only this
pin applied built green on 27 Aug (branch fix_remote_job_lifecycle) with
pyjuliacall 0.9.34, so 0.9.34 with Julia 1.10.11 is known-good here.
Member
|
Already solved in #1001 |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1031 +/- ##
=======================================
Coverage 64.79% 64.79%
=======================================
Files 119 119
Lines 40039 40039
Branches 10350 10350
=======================================
Hits 25942 25942
+ Misses 11121 11119 -2
- Partials 2976 2978 +2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Member
Author
|
superseded by #1001 |
Contributor
There was a problem hiding this comment.
Pull request overview
Pins the Julia version installed in ARC’s Docker image to restore deterministic, reliable Docker builds after the 1.10 juliaup channel began resolving to Julia 1.10.12, which causes a juliacall import segfault during install_rms.sh.
Changes:
- Pin juliaup installation from floating
1.10to fixed1.10.11(installer default-channel,juliaup add, andjuliaup default). - Update Dockerfile comments to document the failure mode and the rationale for the patch pin.
- Align final-stage documentation to reference the pinned Julia patch version.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
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.
The failure
Every push to
mainsince 20 Aug has failed the Docker Image Build and Push workflow (latest run), always in the same layer:That heredoc is install_rms.sh's
from juliacall import Maincheck, andpython << EOF || return 1turns its failure into a failed build. Same segfault in the 20 Aug (job 96581372697) and 24 Aug (job 97406886973) runs, so it is one cause for the whole red streak, not a flake.Root cause
The builder stage asked juliaup for the floating
1.10channel. That channel resolved to 1.10.11 through 16 Aug and to 1.10.12 from 17 Aug, and juliacall segfaults on import under 1.10.12. RMG-Py walked into this first and pinned the same patch version in its CI workflow and Dockerfile in 62eb728c0 ("Pin Julia and openbabel to unbreak CI"); ARC's Dockerfile installs Julia itself and did not follow.The fix
Ask juliaup for
1.10.11instead of1.10, in all three places of the install step. One hunk, plus one final-stage comment line that names the pinned version.Why pyjuliacall is left alone
RMG-Py pinned
pyjuliacall==0.9.28alongside the Julia pin. ARC does not need to follow: the identical Dockerfile with only the Julia pin applied built green on 27 Aug on branchfix_remote_job_lifecycle(job 98677031469, reaching "✅ ReactionMechanismSimulator is succesfully installed!") with pyjuliacall 0.9.34, which is whatpyjuliacall<0.9.35resolves to today. Keeping the change to one variable also keeps the bisect honest.That green run is on a feature branch that also carries unrelated SSH work; this PR isolates the pin so
maincan go green without waiting on it.Known, not fixed here
install_rms.sh's
conda install -y 'conda-forge::pyjuliacall==0.9.28'fails inside the image — in the green run too, so it is not what breaks the build:conda cannot re-solve the
blas=*=openblasspec that RMG-Py'senvironment.ymlrecords into the micromamba-created env. It is silently non-fatal (install_rms.sh does not check the status), but it burned ~30 of the 44 minutes of the failing run and means the upstream pyjuliacall pin never takes effect in this image. Upstream territory; worth its own issue.Verification
CI on this PR is the verifier: the "Build Docker Image (No Push)" job has to get past
install_rms.shto "✅ ReactionMechanismSimulator is succesfully installed!".