fix(manager/mix): run mix commands from the lock file's directory - #44971
Open
zmagajna wants to merge 1 commit into
Open
fix(manager/mix): run mix commands from the lock file's directory#44971zmagajna wants to merge 1 commit into
zmagajna wants to merge 1 commit into
Conversation
|
|
viceice
approved these changes
Jul 30, 2026
Member
|
please sign the cla |
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.
Changes
updateArtifactsin the mix manager now execsmix deps.update/mix deps.getwithcwdFile: lockFileNameinstead ofcwdFile: packageFileName.In Elixir umbrella projects, each app under
apps/*has its ownmix.exs, but the whole umbrella shares a singlemix.lockat the repository root.updateArtifactsalready resolves that shared lock file (viafindLocalSiblingOrParent, settingisUmbrella), but then runsmix deps.update <dep>from the app's directory. Mix resolves the shared lock while seeing only that one app's constraints, silently producing lock entries that violate sibling apps' requirements — e.g. a transitivewebsock_adapterbumped to 0.6.0 while a sibling app'spetal_componentsrequires~> 0.5.7, making the committed lock failmix deps.geteverywhere. In other cases the app-local resolution simply fails (** (Mix) Hex dependency resolution failed), producing artifact errors.Running the command from the lock file's directory resolves the way a developer would at the umbrella root — mix sees every app's constraints. For regular (non-umbrella) projects
mix.lockis a sibling ofmix.exs, so the cwd is unchanged and behavior is identical.Discussion with reproduction details: #43827
The existing "returns updated mix.lock in umbrella project" spec now asserts the exec cwd is the repo root; the subdir (non-umbrella) spec is unchanged.
Context
Please select one of the following:
AI assistance disclosure
Did you use AI tools to create any part of this pull request?
The fix, test change, and PR text were drafted by Claude (Fable 5) via Claude Code, driven and reviewed by me. The root-cause analysis comes from operating Renovate on production Elixir umbrella monorepos.
Documentation (please check one with an [x])
How I've tested my work (please select one)
I have verified these changes via:
pnpm vitest run lib/modules/manager/mix— 89/89 pass. The repositories where the bug bites daily are private (wooga org) umbrella services; we currently work around it withskipArtifactsUpdate+ apostUpgradeTaskscommand runningmix deps.updateat the umbrella root, which has been producing correct locks in production for two weeks — the same resolution this PR performs natively.