Fix downgrade workflow trigger for main#65
Conversation
|
The red downgrade check is an infrastructure failure, not a test result. GitHub's job record shows that resolution and I attempted to rerun only the failed job, but GitHub returned |
|
CI classification after inspecting the red job state:
All three were on |
Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
9a230e6 to
e522369
Compare
|
Rebased the branch onto current main (a56b7cb) after verifying the fork head still matched 9a230e6 exactly. The focused Downgrade.yml main-branch trigger diff is unchanged. Runic passed locally, then I pushed empty co-authored retry commit e522369 to rerun the three jobs that previously lost their self-hosted runners; the retry commit has no tree changes. |
Please ignore this PR until it has been reviewed by @ChrisRackauckas.
Summary
Point both downgrade workflow triggers at the repository's actual default branch,
main, instead of the retiredmastername.The stale pull-request and push filters meant the downgrade workflow did not run for normal
maindevelopment.Local verification
5fdbe2bdusing Julia 1.10.11 andjulia-downgrade-compatfab1def: 1,297/1,297 assertions passed across Core, AD, and Enzyme coverage.Pkg.build()passed in the exact floor environment.actionlint .github/workflows/Downgrade.ymlpassed.git diff --checkpassed.