Tests.yml: run check-compat-bounds as a separate job#67
Merged
Conversation
Move the compat-bounds check out of the `tests` job into a sibling job so a compat failure no longer prevents the test matrix from running. The caller's gate job still aggregates both via `needs:` on the reusable-workflow call, so a failure here continues to block auto-merge. Gate the new job to the canonical (ubuntu-latest, julia=1) cell so it runs exactly once per caller invocation regardless of matrix size, since the check is platform-independent. Also fix check_compat_bounds.jl to not spuriously fail when a workspace project pins its own package to a not-yet-registered version (e.g. root bumps `version = "0.4.0"` and test/docs/examples pin `MyPkg = "0.4"`): merge each workspace project's declared version into the candidate set before computing max_satisfying.
This was referenced Apr 22, 2026
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
1 participant
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.
Summary
testsjob into a siblingcheck-compat-boundsjob inTests.yml. A compat failure no longer prevents the test matrix from running, but still blocks auto-merge via the caller's gate job (whichneeds:the reusable-workflow call and so aggregates both jobs).(ubuntu-latest, julia=1)cell so it runs exactly once per caller invocation regardless of matrix size, since the check is platform-independent.check_compat_bounds.jlto not spuriously fail when a workspace project pins its own package to a not-yet-registered version.The self-compat bug
Reproduced in ITensor/DataGraphs.jl#94:
Root Project.toml bumps
version = "0.4.0"; the workspace subprojects pinDataGraphs = "0.4". Since no0.4.xis registered yet,max_satisfyingreturnednothing→:no_match.The fix:
workspace_versions(projects)reads each workspace Project.toml's(uuid, version), and the main loop merges the workspace version into the candidate set before callingmax_satisfying. Forward-looking self-compat entries that don't match the workspace version (e.g. declaring= "0.5"while root is still0.4.0) still fail as before.Caller impact
None. Existing callers of
ITensor/ITensorActions/.github/workflows/Tests.yml@maindon't need edits:check-compat-bounds/check-compat-bounds-modeinputs are preserved with the same defaults.tests-gatejob (needs: tests) automatically aggregates both reusable jobs — a new job inside the reusable bubbles up through the singleneeds.tests.result.Caveat
The canonical-cell gate assumes every caller's matrix includes
(ubuntu-latest, julia=1). Every ITensor package I looked at does. If that ever breaks down for some package we can swap the gate (e.g. to the lts cell) or expose an input.