fix(cores): pin mgba and fceumm, stop fail-fast hiding broken cores - #17
Merged
Conversation
libretro/mgba deleted Makefile.libretro in 8940477 (2026-08-04) when its libretro CI moved from make to cmake. The core clone is an unpinned shallow clone of upstream HEAD, so from that day on patches/mgba.patch failed to apply and every build-core job died, taking the whole matrix with it via fail-fast - no packaged artifact, no release, on any branch. Pin mgba to 925f0f0, its parent, which is the last commit that still carries the makefile. Verified by checking out that commit and applying both the tg5040 and tg5050 patches with git apply --check: each applies cleanly there and fails against current master. This restores builds; it does not fix the underlying problem. The patch will need porting to cmake before mgba can track upstream again, and every other core is still an unpinned clone that can break the build the same way.
The mgba pin let the matrix get further, and the next unpinned core failed the same way: libretro-fceumm's Makefile.libretro drifted in 8ed0cb2 (2026-07-23, "Replace bundled zlib with libretro-common's clean-room DEFLATE codec") and patches/fceumm.patch no longer applies. Pin to becde7dc, the last commit where it does - verified for both the tg5040 and tg5050 patches, which differ. Also disable fail-fast on the core matrix. With it on, the first broken core cancels the other 40-odd jobs, so each CI round reveals exactly one problem and fixing them becomes serial. Off, one run reports every broken core at once.
5 tasks
lepht
changed the title
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.
Unblocks CI. Works towards #16.
The problem is systemic, not one core
Cores are cloned unpinned and shallow from third-party HEAD, then patched to add the
tg5040/tg5050platform block. When upstream changes the patched file, the patch stops applying and the build dies with no commit on our side.Two have rotted:
mgbaMakefile.libretro: No such file or directory8940477(2026-08-04) deleted it when its CI moved to cmake925f0f0fceummpatch failed: Makefile.libretro:461— context drift8ed0cb2(2026-07-23) replaced bundled zlib with libretro-common's DEFLATE codecbecde7dcThe cores makefile already supports pinning and three cores use it (
fbneo_HASH,picodrive_HASH,pokemini_HASH), so this follows existing convention.Verification
For each pin: fetched that exact commit, then ran
git apply --checkfor both the tg5040 and tg5050 patches, which differ per platform.925f0f0masterbecde7dcmasterAlso confirmed
8940477is a pure 490-line deletion ofMakefile.libretro, and that the file is absent at mgba'smasterbut present at925f0f0.I can't build the cores here — no ARM toolchain or Docker — so CI is the real test.
fail-fast
fail-fast: trueon the core matrix meant the first broken core cancelled the other ~40 jobs. That's how mgba masked fceumm: fixing one revealed the next, one CI round at a time. Turning it off means a single run reports every broken core, so the remainder can be fixed in one pass instead of serially.Expect this run to be noisier — that's the point. If more cores are rotten, we now find out together.
What this does not fix
Merge order
pull_requestruns build the merge commit, so once this lands onmain, #1 goes green without a rebase. #2 and #3 pick it up as the stack merges.