Skip to content

Only force latest compatible versions on the newest Julia - #3

Merged
lkdvos merged 1 commit into
mainfrom
ld-no-force-latest-on-old-julia
Aug 30, 2026
Merged

Only force latest compatible versions on the newest Julia#3
lkdvos merged 1 commit into
mainfrom
ld-no-force-latest-on-old-julia

Conversation

@lkdvos

@lkdvos lkdvos commented Aug 30, 2026

Copy link
Copy Markdown
Member

Every non-newest job in a TestGroups.yml matrix fails to resolve — before running a single test — on any Dependabot or CompatHelper branch.

Cause

julia-actions/julia-runtest defaults force_latest_compatible_version to auto, and auto is resolved purely by branch name (autodetect-dependabot.jl):

_is_dependabot_branch(b) = startswith(b, "dependabot/julia") || startswith(b, "compathelper/")

On such a branch it becomes true, which pins every [compat] entry to its newest range. That is fundamentally at odds with testing an older Julia: the newest release of a dependency routinely drops support for it, and the resolver then has nothing left to pick.

TestGroups.yml never sets the input, so it inherits auto for every entry in the matrix, min included.

Observed

QuantumKitHub/TensorKit.jl#495 is a Dependabot PR bumping the JET compat entry. Result: 33 min jobs failed, 33 1 jobs passed — the entire min half of the matrix, across all three operating systems and every test group.

ERROR: LoadError: Unsatisfiable requirements detected for package JET [c3a54625]:
 ├─restricted to versions [0.9, 0.12] by project
 ├─restricted to versions 0.12 by an explicit requirement    ← force_latest_compatible_version
 └─restricted by julia compatibility requirements to versions: 0.8.22-0.9.18 — no versions left

min there is Julia 1.10.12, where JET is capped at 0.9.18, while JET 0.12 requires Julia ≥ 1.12.

This is not specific to that compat entry, or to that PR. Checked against the registry on Julia 1.10.11:

pin JET=0.9   -> resolves 0.9.18   ✓
pin JET=0.11  -> unsatisfiable         ← the entry currently on TensorKit's main
pin JET=0.12  -> unsatisfiable         ← the entry the PR proposes

So the same failure occurs with the compat entry already on main; the two previous Dependabot PRs to that repo (#490, #445) show the identical all-min failure pattern. Any repo using this workflow hits it the moment a test dependency's newest range stops supporting the min Julia.

Change

Restrict the flag to the newest Julia, and let callers override it:

force_latest_compatible_version: "${{ matrix.version == '1' && inputs.force-latest-compatible-version || 'false' }}"

This keeps the signal the flag exists for — does this compat bump actually work against the newest dependencies? — on 1, and lets the other matrix entries resolve normally. Gating on matrix.version == '1' matches how coverage is already gated in the same step.

The new force-latest-compatible-version input defaults to auto, so behaviour on 1 is unchanged. Setting it to false disables the flag everywhere; setting it to true forces it on 1 only.

Notes

  • Tests.yml calls julia-runtest the same way and has the same defect, but takes a scalar julia-version rather than a matrix, so the condition would differ. Left alone here — happy to fold it in if you'd like it fixed in one go.
  • YAML validated by parsing; the A && B || C idiom is already used in this step for test_args. Note 'false' is a non-empty (truthy) string, so an explicit false input propagates correctly rather than falling through to the fallback.

🤖 Generated with Claude Code

`julia-actions/julia-runtest` resolves `force_latest_compatible_version: auto`
to `true` whenever the branch starts with `dependabot/julia` or `compathelper/`,
which pins every `[compat]` entry to its newest range. On an older Julia that is
unsatisfiable as soon as a dependency's newest range drops support for it, so
every non-newest job in the matrix fails to resolve before running a test.

Restrict it to `matrix.version == '1'`, matching how coverage is already gated,
and expose `force-latest-compatible-version` so callers can override it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@lkdvos
lkdvos merged commit 67f16be into main Aug 30, 2026
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.

1 participant