Repository navigation
ilammy/msvc-dev-cmd (node20) has no fix — breaks MSVC Windows CI after 2026-09-23 #167
Description
Activity
- added a commit that references this issue
on Sep 25, 2026 It seems that the second issue you brought up is out of our hands, we'll need to wait until they update until we can completely fix this issue. I accepted PR #166 and I guess we'll wait until fortran-lang makes the required changes.
Thanks for merging #166. Correction on my part: the second path in this issue doesn't actually affect CEA, so there's nothing to wait on from fortran-lang.
fortran-lang/setup-fortran@v1only runs its internalilammy/msvc-dev-cmdstep when the compiler islfortran(action.yml):- name: Setup MSVC toolchain (Windows) if: runner.os == 'Windows' && contains(inputs.compiler, 'lfortran') uses: ilammy/msvc-dev-cmd@v1.13.0
CEA's workflows never use
lfortran, so that step is always skipped. I misread the condition as covering Windows/Intel when I filed this.Confirmed in CI after the 2026-09-23 cutoff: the
windows-latest / msvc / inteljob passed on 2026-09-25 (https://github.com/djkees/cea/actions/runs/36170574715/job/108188831937), and its log shows the step skipped:##[end-action id=__fortran-lang_setup-fortran.__ilammy_msvc-dev-cmd;outcome=skipped;conclusion=skipped;duration_ms=0]With #166 merged, CEA's only real use of
ilammy/msvc-dev-cmdis gone, so I think this can be closed. I'll correct the scope on fortran-lang/setup-fortran#275 as well, since it only matters forlfortranusers there.
Problem / use case
Found while auditing #165 (the checkout/setup-python node20 fix, see #166) for completeness:
ilammy/msvc-dev-cmd@v1also declaresnode20in its ownaction.yml, and unlikeactions/checkout/actions/setup-python/etc., there's no newer major version to bump to — the upstream repo's most recent commit is from April 2024, and its most recent release (v1.13.0, also April 2024) is stillnode20. A few community PRs proposing a Node 24 update are open there but unmerged.Once the Node20 compatibility shim is removed on 2026-09-23 (per the GitHub changelog), an action still declaring
node20will fail to run rather than just warn.This hits exactly one CI job —
basic_build.yml'sbindcjob,windows-latest / msvc / intelmatrix entry — through two separate paths that both need fixing, not one:ilammy/msvc-dev-cmd@v1directly.fortran-lang/setup-fortran@v1(sincefcompiler == 'intel'), which internally pinsilammy/msvc-dev-cmd@v1.13.0for its own Windows/Intel setup.Fixing only (1) does not save the job — (2) still breaks it, and CEA has no way to override a dependency pinned inside another project's action.
Fix status
ilammy/msvc-dev-cmd@v1→step-security/msvc-dev-cmd@v1, a verified drop-in mirror (same inputs/usage) maintained by StepSecurity (a supply-chain security vendor, also behindharden-runner) that declaresnode24and has an active maintenance history (routine dependency/audit fixes through September 2026). Adopting it does mean trusting a new third party CEA doesn't currently depend on — flagging that as a deliberate call, not a hidden default.fortran-lang/setup-fortran@v1's internal usage — not fixable from CEA's side. Filed fortran-lang/setup-fortran#275 proposing the same swap there, as a minimal patch to thev1track (independent of their in-progressv2rewrite, which already drops this dependency entirely but is still beta — see fortran-lang/setup-fortran#245). Until that lands upstream, this job will still break on 2026-09-23 regardless of what CEA does in its own repo.Additional context
🤖 Generated with Claude Code