CheckCompatBounds: extract compat-bounds check into its own workflow#69
Merged
CheckCompatBounds: extract compat-bounds check into its own workflow#69
Conversation
Move the compat-bounds check out of Tests.yml into a new reusable workflow CheckCompatBounds.yml. The check no longer runs once per Tests-matrix cell; instead callers invoke CheckCompatBounds.yml as a separate, unmatrixed workflow and get a single clean status per PR. - Add .github/workflows/CheckCompatBounds.yml (reusable workflow). - Remove the `check-compat-bounds` job and its two inputs (`check-compat-bounds`, `check-compat-bounds-mode`) from Tests.yml. A search across ITensor-org callers found no workflows that set either input, so this is a safe removal. - Rework the README: drop the "Compat upper-bound check" subsection under Tests, and add a new top-level "Check Compat Bounds" section documenting the new workflow and its inputs. Rolling out to callers (new per-repo workflow + ITensorPkgSkeleton template) will follow via ITensorOrgPatches.
This was referenced Apr 22, 2026
mtfishman
added a commit
that referenced
this pull request
Apr 22, 2026
Tiny follow-up to #69. The reusable workflow's job `name:` was lowercase `"Check compat bounds"`; title-case it to produce a clean `"Check Compat Bounds / Check Compat Bounds"` status-check context for branch protection.
mtfishman
added a commit
to ITensor/ITensorPkgSkeleton.jl
that referenced
this pull request
Apr 22, 2026
## Summary Follow-up to [ITensorActions#69](ITensor/ITensorActions#69), which introduced the `CheckCompatBounds.yml` reusable workflow. This PR adds the caller workflow to ITensorPkgSkeleton.jl so: - New packages generated from the skeleton get the check out of the box. - `ITensorOrgPatches` / `MassApplyPatch` can pick the file up via `add_template_file!(\".github/workflows/CheckCompatBounds.yml\")` and roll it out across existing ecosystem packages. Added in both locations (per the skeleton's convention): - `.github/workflows/CheckCompatBounds.yml` — the skeleton's own CI. - `template/.github/workflows/CheckCompatBounds.yml.template` — the template. Patch version bumped to 0.3.50 since this is a substantive template change.
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
Follow-up to #67 (which put the check as a sibling job inside
Tests.yml). BecauseTests.ymlis typically invoked via a caller-side matrix, any job inside it is multiplied by the matrix — producing either gray skipped checks (job-level gate) or misleading green checks (step-level gate). There is no way within a reusable workflow to know it's one of N matrix invocations, so the fix is to lift the check out ofTests.ymlentirely.This PR:
CheckCompatBounds.ymlthat runs the compat-bounds check once per invocation onubuntu-latest.check-compat-boundsjob and its two inputs (check-compat-bounds,check-compat-bounds-mode) fromTests.yml.The input removal is safe: a code search across the ITensor org turned up zero callers that set either input; the only hits are inside
Tests.ymlitself.Caller-side rollout (separate)
Each caller needs a new one-line workflow that invokes
CheckCompatBounds.yml@main. I'll do that viaITensorOrgPatches/MassApplyPatchin a follow-up, plus a matching template inITensorPkgSkeleton.jlfor new packages. Until that lands, no caller runs the check — same effective state as the previous job-level gate on non-matching matrix cells.Minimal caller workflow: