Repository navigation
ci: fix the MSYS2 Windows job (UCRT64) and clear out workflow drift - #597
Merged
Merged
Conversation
MSYS2 merged "Drop mingw64 for some packages" (MINGW-packages 5d003630a,
2026-10-16) which removed mingw64 from hidapi's mingw_arch, leaving it at
('ucrt64' 'clang64' 'clangarm64'). mingw-w64-x86_64-hidapi no longer exists
in any repo, so Setup MSYS2 fails with "target not found" before anything is
compiled. Every push and PR has been red since.
Package versions cannot be pinned the way the actions are: setup-msys2
re-downloads the repo databases on every run, so the job always resolves
against MSYS2's current repo state.
UCRT64 is where MSYS2 is heading -- the msvcrt-based environments are being
retired package by package, and gcc/cmake/ninja are on the same path. Verified
on a Windows box: configures against ucrt64/libhidapi.a, builds clean with
GCC 16.1.0, both ctest tests pass.
The PPA publishes gcc-14, gcc-15 and amdgcn-tools for noble and nothing at all for gcc-13, for any series. The gcc-13 the job installs has always come from the Ubuntu archive (13.3.0 on noble, 13.4.0 on resolute), so the add-apt-repository call only added a network dependency and a failure mode. Keeping the gcc-13 pin itself: it is the floor CMakeLists.txt enforces, so CI should go on building with it.
Every other action in the repository is pinned to a SHA with the version in a trailing comment; this one tracked the v1 tag. v1 is a rolling tag -- it was last moved on 2026-10-19 -- so the workflow holding CLAUDE_CODE_OAUTH_TOKEN was the one action that could change under us without a commit here. Pinned to the commit v1 currently resolves to.
The pin was the 2025.12.12 release, ten months old. Moved to the newest tagged vcpkg release rather than a branch tip, so the port versions stay curated and reproducible. Only hidapi and getopt are consumed, so the exposure is small, but this is the Windows release binary -- worth watching the first run.
resolute (26.04 LTS) released in April and is Supported on Launchpad, so it meets the GCC 13+ rule this workflow already documents -- it ships GCC 15 and debian/control pins no compiler. Untested: the PPA has only ever published noble, and this runs on a release tag, so the first resolute upload happens at the next release. fail-fast is already off, so a resolute failure cannot take noble down with it.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
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
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.
Windows CI has been red on every push and PR since 2026-10-16. Fixes that, plus four pieces of drift found while auditing the other workflows.
The break
Setup MSYS2fails before anything compiles:MSYS2 merged
Drop mingw64 for some packages(MINGW-packages#32512) at 2026-10-16 11:30 UTC, which left hidapi atmingw_arch=('ucrt64' 'clang64' 'clangarm64'). The last green run was 2026-10-15 22:13 UTC and the first red one 2026-10-16 14:33 UTC — a three-hour window.Nothing here could have prevented it:
setup-msys2re-downloads the repo databases every run, so the job always resolves against MSYS2's current repo state. Pacman package versions can't be pinned the way the actions are.Switching to UCRT64 is the direction MSYS2 is moving — the msvcrt-based environments are being retired package by package, and
gcc/cmake/ninjaare on the same path.Verified on a Windows box before pushing: configures against
ucrt64/libhidapi.a, builds clean with GCC 16.1.0, both ctest tests pass.The rest
ubuntu-toolchain-r/testPPA. It publishesgcc-14,gcc-15andamdgcn-toolsfor noble and nogcc-13for any series. Thegcc-13being installed has always come from the Ubuntu archive. Thegcc-13pin itself stays — it is the floorCMakeLists.txtenforces.claude-code-action. The only unpinned action in a repo that SHA-pins everything else, andv1is a rolling tag last moved on 2026-10-19.Worth a look after merge
The vcpkg bump touches the Windows release binary.
continuos-release.ymlexercises it on push to master, so the first run after merge is the real check.The resolute PPA upload is untested — it only fires on a release tag, and the PPA has only ever published noble.
fail-fastis already off, so a resolute failure can't take noble down with it.Checked, no change needed
The
ubuntu-latest→ Ubuntu 26 migration that started 2026-10-19 does not break anything:gcc-13is in the resolute archive (13.4.0) and the PPA serves a validReleasefile for it.build-artifacts.ymlpinsubuntu-22.04deliberately and is insulated either way.The
bump-homebrewfailure from 2026-08-27 is not a bug — twoworkflow_dispatchruns ten seconds apart during the 4.1.0 release, the second hit abrewtimeout.