tests.yml: set group env via shell: bash so GROUP propagates on Windows#100
Draft
ChrisRackauckas-Claude wants to merge 1 commit into
Draft
Conversation
The "Set test group env" step writes `<group-env-name>=<group>` to $GITHUB_ENV with bash syntax but declared no `shell:`, so it ran under the windows runners' default shell (PowerShell). PowerShell does not expand the bash-style "$GITHUB_ENV"; the step wrote to a file literally named $GITHUB_ENV instead of appending to the runner's environment file, so the group env var (e.g. GROUP) was silently never set on Windows. With GROUP unset, a package's runtests.jl falls back to its default group (SciMLTesting's run_tests defaults to "All"), so a matrix entry scheduled as "Core" on windows-latest actually ran every group's folder -- including groups with their own test/<Group>/Project.toml (e.g. an AD group pulling SciMLSensitivity) -- inside the main test environment. That activated a second project mid-session and upgraded already-loaded packages, producing precompile conflicts (observed in DiffEqCallbacks.jl: OrdinaryDiffEqCorePolyesterExt referencing OrdinaryDiffEqCore._polyester_batch against a stale loaded OrdinaryDiffEqCore) and a windows-only red. Linux/macOS runners default to bash and were unaffected. Add `shell: bash` so $GITHUB_ENV expands on every OS and the group is set correctly on Windows. downgrade.yml is unaffected (it sets GROUP via the step `env:` map, which is shell-independent). Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
ChrisRackauckas
added a commit
to SciML/DiffEqCallbacks.jl
that referenced
this pull request
Jun 26, 2026
…; Windows fixed via SciML/.github#100 (#318) * Fix docs Euler import (OrdinaryDiffEq v7 split) and raise OrdinaryDiffEqBDF downgrade floor Two master-CI failures, two independent fixes: Documentation build (UndefVarError: `Euler` not defined): OrdinaryDiffEq v7 split out the low-order RK solvers and no longer re-exports `Euler` from the umbrella (verified: with OrdinaryDiffEq v7.0.1, isdefined(OrdinaryDiffEq, :Euler) == false; `Euler` now lives in OrdinaryDiffEqLowOrderRK). The docs examples in integrating.md and uncertainty_quantification.md call `Euler()` with only `using OrdinaryDiffEq`, so the @example blocks errored. Add OrdinaryDiffEqLowOrderRK to docs/Project.toml and `using` it in both pages. Higher-order solvers (Tsit5, Rodas5P, Rosenbrock23, Vern7) are still re-exported by the umbrella and need no change. Downgrade (Core) (MethodError: no method matching _initialize_dae! for the NonlinearSolve-backed BrownFullBasicInit in saving_tests.jl's "fail gracefully" DAE test): the `_initialize_dae!(..., BrownFullBasicInit{..., GeneralizedFirstOrderAlgorithm})` dispatch is implemented in OrdinaryDiffEqBDF and first appears in v1.7.0. The previous compat floor "1.3.0" let the downgrade resolve OrdinaryDiffEqBDF v1.3.0, which lacks the method, so the test errored instead of returning ReturnCode.InitialFailure. Bisected locally on Julia 1.10: BDF 1.6.0 errors, BDF 1.7.0 passes; raise the floor to 1.7.0 (a lower-bound raise is downgrade-safe and the repo already allows BDF v2). Verified locally on Julia 1.10 that the fail-gracefully test returns InitialFailure with the bumped floor, and on Julia 1.12 that the integrating.md example runs with the docs env. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * Raise DiffEqBase downgrade floor to 6.211.0 (fixes Downgrade Core) The strict Downgrade (Core) job still failed after the OrdinaryDiffEqBDF floor bump: the "fail gracefully" DAE test in saving_tests.jl errored with a MethodError for _initialize_dae!(..., BrownFullBasicInit{..., GeneralizedFirstOrderAlgorithm}, ::Val{false}) even with OrdinaryDiffEqBDF v1.8.0 resolved -- so the BDF floor was not the real cause. Root cause (reproduced locally on Julia 1.10 with the CI-resolved downgrade stack): DiffEqBase v6.190.2's DiffEqBaseChainRulesCoreExt defines ChainRulesCore.rrule(::typeof(numargs), f), and SciMLBase v2.146.0's SciMLBaseChainRulesCoreExt defines the same rrule for SciMLBase.numargs. With both floors resolved together the duplicate definition raises "Method overwriting is not permitted during Module precompilation" while loading DiffEqBaseChainRulesCoreExt, which fails the extension and cascades so the OrdinaryDiffEqNonlinearSolve _initialize_dae! methods for BrownFullBasicInit are never available -- hence the MethodError (the listed candidates were only the OrdinaryDiffEqCore CheckInit/OverrideInit/NoInit methods). DiffEqBase removed rrule(numargs) from its ext in v6.211.0 (verified: present in 6.210.0, absent from 6.211.0; SciMLBase owns it now). Raising the floor to 6.211.0 drops the version range that double-defines it; SciMLBase 2.146.0 still provides the rrule, so nothing is lost. A lower-bound raise is downgrade-safe. Verified locally on Julia 1.10: with DiffEqBase pinned to 6.211.0 against the CI downgrade stack (SciMLBase 2.146.0, OrdinaryDiffEqBDF 1.8.0, OrdinaryDiffEqNonlinearSolve 1.12.0, NonlinearSolveFirstOrder 1.9.0) the stack precompiles with no method-overwriting error and the "fail gracefully" testset passes 4/4 (sol.retcode == ReturnCode.InitialFailure). Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test_groups: exclude AD and QA from the "All" aggregate (in_all=false) The AD group (SciMLSensitivity/Zygote/Enzyme) was folded into "All", so the secondary-OS/aggregate legs globbed test/AD/ and failed on windows-latest (Enzyme is unreliable off Linux): AD/integrating_sensitivity_tests.jl errored, sinking the Core (windows) job. Mark [AD] in_all=false so it runs only as its own Linux, non-prerelease group; mark [QA] in_all=false explicitly (QA is always its own lane). All coverage is preserved — AD/QA still run as named groups. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: ChrisRackauckas-Claude <accounts@chrisrackauckas.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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
2 participants
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.
Problem
The
Set test group envstep intests.ymlwrites<group-env-name>=<group>to$GITHUB_ENVusing bash$VARsyntax but declares noshell:. On windows runners the default shell is PowerShell, which does not expand"$GITHUB_ENV"the bash way — it writes to a file literally named$GITHUB_ENVrather than appending to the runner environment file. Result: the group env var (e.g.GROUP) is silently never set on Windows.With
GROUPunset, a package'sruntests.jlfalls back to its default group (SciMLTesting'srun_tests()defaults to"All"). So a matrix entry scheduled as Core on windows-latest actually ran every group folder, including groups that carry their owntest/<Group>/Project.toml(e.g. an AD group depending on SciMLSensitivity) — inside the main test environment. Activating that second project mid-session upgrades already-loaded packages and triggers precompile conflicts.Observed in SciML/DiffEqCallbacks.jl
tests / Core (julia 1|lts, windows-latest)failed with:because the Core job leaked into the
ADgroup (Activating project at ...\test\AD,OrdinaryDiffEqCore v4.3.0 [loaded: v3.33.1]) andusing SciMLSensitivityfailed to precompile against the stale loadedOrdinaryDiffEqCore. Linux/macOS Core jobs (bash default) ran only the Core folder and passed.Fix
Add
shell: bashto theSet test group envstep so$GITHUB_ENVexpands on every OS and the group is set correctly on Windows. This is the same shell the adjacent GITHUB_ENV/GITHUB_OUTPUT steps already use.downgrade.ymlis unaffected: it setsGROUPvia the runtest step'senv:map (shell-independent).This fixes Windows grouped-tests for every SciML repo that uses
grouped-tests.yml/tests.yml, not just DiffEqCallbacks.jl.v1will need to be retagged to this commit for callers pinned at@v1to pick it up.Please ignore until reviewed by @ChrisRackauckas