Skip to content

fix(manager/mix): run mix commands from the lock file's directory - #44971

Open
zmagajna wants to merge 1 commit into
renovatebot:mainfrom
zmagajna:fix/mix-umbrella-lockfile-cwd
Open

fix(manager/mix): run mix commands from the lock file's directory#44971
zmagajna wants to merge 1 commit into
renovatebot:mainfrom
zmagajna:fix/mix-umbrella-lockfile-cwd

Conversation

@zmagajna

Copy link
Copy Markdown

Changes

updateArtifacts in the mix manager now execs mix deps.update / mix deps.get with cwdFile: lockFileName instead of cwdFile: packageFileName.

In Elixir umbrella projects, each app under apps/* has its own mix.exs, but the whole umbrella shares a single mix.lock at the repository root. updateArtifacts already resolves that shared lock file (via findLocalSiblingOrParent, setting isUmbrella), but then runs mix 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 transitive websock_adapter bumped to 0.6.0 while a sibling app's petal_components requires ~> 0.5.7, making the committed lock fail mix deps.get everywhere. 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.lock is a sibling of mix.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:

  • This closes an existing Issue, Closes: #
  • This doesn't close an Issue, but I accept the risk that this PR may be closed if maintainers disagree with its opening or implementation

AI assistance disclosure

Did you use AI tools to create any part of this pull request?

  • No — I did not use AI for this contribution.
  • Yes — minimal assistance (e.g., IDE autocomplete, small code completions, grammar fixes).
  • Yes — substantive assistance (AI-generated non‑trivial portions of code, tests, or documentation).
  • Yes — other (please describe):

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])

  • I have updated the documentation, or
  • No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

  • Code inspection only, or
  • Newly added/modified unit tests, or
  • No unit tests, but ran on a real repository, or
  • Both unit tests + ran on a real repository

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 with skipArtifactsUpdate + a postUpgradeTasks command running mix deps.update at the umbrella root, which has been producing correct locks in production for two weeks — the same resolution this PR performs natively.

@github-actions
github-actions Bot requested a review from viceice July 30, 2026 16:18
@cla-assistant

cla-assistant Bot commented Jul 30, 2026

Copy link
Copy Markdown

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

@viceice

viceice commented Jul 30, 2026

Copy link
Copy Markdown
Member

please sign the cla

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants