ci: compile pull requests on the Ubuntu the release compiles on - #580
Merged
Conversation
test_build.yml's Linux entry has said ubuntu-22.04 since the commit that created the workflow -- `git log -S` finds exactly one, "added test and build workflows" -- while build.yml moved to ubuntu-24.04 and has been maintained there through #499's AppImage strip and #463's WebKitGTK unpin. Nothing chose 22.04; nothing revisited it either. Two Ubuntus are two sets of system libraries, so the platform check was answering a question nobody asked: "the pull request compiled" did not mean "the release will". And the AppImage a pull request produces bundles libraries from a release nothing ships -- the class of defect #463 and #498 both were. The other direction is the usual AppImage advice: build on the older distribution, because a binary linked against an older glibc runs on more systems. It is not available here. jammy's WebKitGTK is older than noble's, and older WebKitGTK failing EGL against current Mesa is precisely #463. Releasing from 22.04 means solving that again. One assertion, in the shape of the Node one beside it: the two workflows are compared against each other rather than against a literal, so a named version does not become a fourth place to update. Checked by mutation -- restoring 22.04 fails it, and nothing else. 974 tests pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Extends this branch after its own first run failed.
test.yml runs on ubuntu-22.04 too, and it runs `cargo test` behind the same
apt list -- so the third compiling workflow was on the third environment, not
the second. It moves to 24.04 with the others.
And the first attempt here broke, which is the more useful half. Moving
test_build.yml's matrix to 24.04 left `install dependencies (ubuntu only)`
asking for `matrix.platform == 'ubuntu-22.04'`, so it was skipped in silence
and `cargo test` failed on a missing libwebkit2gtk-4.1-dev -- a failure that
said nothing about the change that caused it (run 31486273066). build.yml
repeats the same pattern twelve times.
Every matrix already carries a stable name for the entry -- `os` in build.yml,
`os-name` in test_build.yml -- that does not change when the runner does. All
thirteen conditions now use it, and no workflow branches on a runner name. The
runner is written where the matrix declares it and nowhere else.
Two assertions, both checked by mutation, both failing alone:
- reverting test.yml to 22.04 fails "every workflow that compiles compiles
on the same Ubuntu"
- reverting one condition fails "a step asks which matrix entry it is"
The first mutation check for the second assertion silently did not mutate --
BSD sed ignores `0,/re/s//repl/` -- and reported a pass. Redone with the edit
verified before the run. 975 tests pass.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This was referenced Aug 11, 2026
PathGao
pushed a commit
that referenced
this pull request
Aug 11, 2026
Stacked on ci/one-linux-dependency-list. Two questions about the Linux artifact that nothing has been answering, and one comment that was about to become false. `check-appimage-libraries.sh`, on every pull request. strip-appimage.sh proves its six libraries are gone afterwards; that is "we removed what we meant to", not "six is still the right number". What decides the right number is not in this repository -- `tauri build` fetches linuxdeploy-plugin-gtk from the tip of someone else's branch on every run, so the set copied into the AppDir can change with no commit here, no pull request and no notification. The script intersects what is bundled with the AppImage project's own excludelist and requires the result to equal the strip list exactly, in both directions. It reads that list out of strip-appimage.sh rather than restating it. It runs on the pull request build because that AppImage is the un-stripped one, which for this question is the right artifact rather than a worse one. It only became comparable when #580 moved this job to the release's Ubuntu. `smoke-appimage.sh`, on the release, after the re-sign and before the upload. strip-appimage.sh said a CI smoke test cannot catch this defect because the runner's Mesa is the one the libraries came from -- true of the runner, and only of the runner. A container is another distribution's userspace on the same kernel, which is a host that can disagree. The comment now says so. Liveness is not the check. #499 records that the GTK shell survives while WebKit's WebProcess aborts behind a blank window, so both defects this exists to catch would have passed a "is it still running" test. It greps for the abort, and keeps the liveness check as the backstop for a reworded one. Both scripts also run on pull requests, after a strip, and that is the point rather than thoroughness: smoke-appimage.sh would otherwise reach the release path having never run anywhere, and strip-appimage.sh has never run outside a release -- it failed in two of the three v2.7.2 release attempts. Roughly three minutes on a twelve-minute job. Also, one line in dependabot.yml: the github-actions ecosystem covers `uses:` and not `runs-on:`, so nothing proposes ubuntu-24.04 -> 26.04 and nobody should assume something is watching. Three assertions, each checked by mutation and each failing alone: smoking before the strip, dropping the release smoke, and restating the library list in the new script. 979 pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
PathGao
pushed a commit
that referenced
this pull request
Aug 11, 2026
Stacked on ci/one-linux-dependency-list. Two questions about the Linux artifact that nothing has been answering, and one comment that was about to become false. `check-appimage-libraries.sh`, on every pull request. strip-appimage.sh proves its six libraries are gone afterwards; that is "we removed what we meant to", not "six is still the right number". What decides the right number is not in this repository -- `tauri build` fetches linuxdeploy-plugin-gtk from the tip of someone else's branch on every run, so the set copied into the AppDir can change with no commit here, no pull request and no notification. The script intersects what is bundled with the AppImage project's own excludelist and requires the result to equal the strip list exactly, in both directions. It reads that list out of strip-appimage.sh rather than restating it. It runs on the pull request build because that AppImage is the un-stripped one, which for this question is the right artifact rather than a worse one. It only became comparable when #580 moved this job to the release's Ubuntu. `smoke-appimage.sh`, on the release, after the re-sign and before the upload. strip-appimage.sh said a CI smoke test cannot catch this defect because the runner's Mesa is the one the libraries came from -- true of the runner, and only of the runner. A container is another distribution's userspace on the same kernel, which is a host that can disagree. The comment now says so. Liveness is not the check. #499 records that the GTK shell survives while WebKit's WebProcess aborts behind a blank window, so both defects this exists to catch would have passed a "is it still running" test. It greps for the abort, and keeps the liveness check as the backstop for a reworded one. Both scripts also run on pull requests, after a strip, and that is the point rather than thoroughness: smoke-appimage.sh would otherwise reach the release path having never run anywhere, and strip-appimage.sh has never run outside a release -- it failed in two of the three v2.7.2 release attempts. Roughly three minutes on a twelve-minute job. Also, one line in dependabot.yml: the github-actions ecosystem covers `uses:` and not `runs-on:`, so nothing proposes ubuntu-24.04 -> 26.04 and nobody should assume something is watching. Three assertions, each checked by mutation and each failing alone: smoking before the strip, dropping the release smoke, and restating the library list in the new script. 979 pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
PathGao
pushed a commit
that referenced
this pull request
Aug 11, 2026
Stacked on ci/one-linux-dependency-list. Two questions about the Linux artifact that nothing has been answering, and one comment that was about to become false. `check-appimage-libraries.sh`, on every pull request. strip-appimage.sh proves its six libraries are gone afterwards; that is "we removed what we meant to", not "six is still the right number". What decides the right number is not in this repository -- `tauri build` fetches linuxdeploy-plugin-gtk from the tip of someone else's branch on every run, so the set copied into the AppDir can change with no commit here, no pull request and no notification. The script intersects what is bundled with the AppImage project's own excludelist and requires the result to equal the strip list exactly, in both directions. It reads that list out of strip-appimage.sh rather than restating it. It runs on the pull request build because that AppImage is the un-stripped one, which for this question is the right artifact rather than a worse one. It only became comparable when #580 moved this job to the release's Ubuntu. `smoke-appimage.sh`, on the release, after the re-sign and before the upload. strip-appimage.sh said a CI smoke test cannot catch this defect because the runner's Mesa is the one the libraries came from -- true of the runner, and only of the runner. A container is another distribution's userspace on the same kernel, which is a host that can disagree. The comment now says so. Liveness is not the check. #499 records that the GTK shell survives while WebKit's WebProcess aborts behind a blank window, so both defects this exists to catch would have passed a "is it still running" test. It greps for the abort, and keeps the liveness check as the backstop for a reworded one. Both scripts also run on pull requests, after a strip, and that is the point rather than thoroughness: smoke-appimage.sh would otherwise reach the release path having never run anywhere, and strip-appimage.sh has never run outside a release -- it failed in two of the three v2.7.2 release attempts. Roughly three minutes on a twelve-minute job. Also, one line in dependabot.yml: the github-actions ecosystem covers `uses:` and not `runs-on:`, so nothing proposes ubuntu-24.04 -> 26.04 and nobody should assume something is watching. Three assertions, each checked by mutation and each failing alone: smoking before the strip, dropping the release smoke, and restating the library list in the new script. 979 pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
PathGao
pushed a commit
that referenced
this pull request
Aug 11, 2026
Stacked on ci/one-linux-dependency-list. Two questions about the Linux artifact that nothing has been answering, and one comment that was about to become false. `check-appimage-libraries.sh`, on every pull request. strip-appimage.sh proves its six libraries are gone afterwards; that is "we removed what we meant to", not "six is still the right number". What decides the right number is not in this repository -- `tauri build` fetches linuxdeploy-plugin-gtk from the tip of someone else's branch on every run, so the set copied into the AppDir can change with no commit here, no pull request and no notification. The script intersects what is bundled with the AppImage project's own excludelist and requires the result to equal the strip list exactly, in both directions. It reads that list out of strip-appimage.sh rather than restating it. It runs on the pull request build because that AppImage is the un-stripped one, which for this question is the right artifact rather than a worse one. It only became comparable when #580 moved this job to the release's Ubuntu. `smoke-appimage.sh`, on the release, after the re-sign and before the upload. strip-appimage.sh said a CI smoke test cannot catch this defect because the runner's Mesa is the one the libraries came from -- true of the runner, and only of the runner. A container is another distribution's userspace on the same kernel, which is a host that can disagree. The comment now says so. Liveness is not the check. #499 records that the GTK shell survives while WebKit's WebProcess aborts behind a blank window, so both defects this exists to catch would have passed a "is it still running" test. It greps for the abort, and keeps the liveness check as the backstop for a reworded one. Both scripts also run on pull requests, after a strip, and that is the point rather than thoroughness: smoke-appimage.sh would otherwise reach the release path having never run anywhere, and strip-appimage.sh has never run outside a release -- it failed in two of the three v2.7.2 release attempts. Roughly three minutes on a twelve-minute job. Also, one line in dependabot.yml: the github-actions ecosystem covers `uses:` and not `runs-on:`, so nothing proposes ubuntu-24.04 -> 26.04 and nobody should assume something is watching. Three assertions, each checked by mutation and each failing alone: smoking before the strip, dropping the release smoke, and restating the library list in the new script. 979 pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
PathGao
pushed a commit
that referenced
this pull request
Aug 11, 2026
Stacked on ci/one-linux-dependency-list. Two questions about the Linux artifact that nothing has been answering, and one comment that was about to become false. `check-appimage-libraries.sh`, on every pull request. strip-appimage.sh proves its six libraries are gone afterwards; that is "we removed what we meant to", not "six is still the right number". What decides the right number is not in this repository -- `tauri build` fetches linuxdeploy-plugin-gtk from the tip of someone else's branch on every run, so the set copied into the AppDir can change with no commit here, no pull request and no notification. The script intersects what is bundled with the AppImage project's own excludelist and requires the result to equal the strip list exactly, in both directions. It reads that list out of strip-appimage.sh rather than restating it. It runs on the pull request build because that AppImage is the un-stripped one, which for this question is the right artifact rather than a worse one. It only became comparable when #580 moved this job to the release's Ubuntu. `smoke-appimage.sh`, on the release, after the re-sign and before the upload. strip-appimage.sh said a CI smoke test cannot catch this defect because the runner's Mesa is the one the libraries came from -- true of the runner, and only of the runner. A container is another distribution's userspace on the same kernel, which is a host that can disagree. The comment now says so. Liveness is not the check. #499 records that the GTK shell survives while WebKit's WebProcess aborts behind a blank window, so both defects this exists to catch would have passed a "is it still running" test. It greps for the abort, and keeps the liveness check as the backstop for a reworded one. Both scripts also run on pull requests, after a strip, and that is the point rather than thoroughness: smoke-appimage.sh would otherwise reach the release path having never run anywhere, and strip-appimage.sh has never run outside a release -- it failed in two of the three v2.7.2 release attempts. Roughly three minutes on a twelve-minute job. Also, one line in dependabot.yml: the github-actions ecosystem covers `uses:` and not `runs-on:`, so nothing proposes ubuntu-24.04 -> 26.04 and nobody should assume something is watching. Three assertions, each checked by mutation and each failing alone: smoking before the strip, dropping the release smoke, and restating the library list in the new script. 979 pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
PathGao
added a commit
that referenced
this pull request
Aug 11, 2026
* ci: ask the AppImage what it bundles, and whether it starts Stacked on ci/one-linux-dependency-list. Two questions about the Linux artifact that nothing has been answering, and one comment that was about to become false. `check-appimage-libraries.sh`, on every pull request. strip-appimage.sh proves its six libraries are gone afterwards; that is "we removed what we meant to", not "six is still the right number". What decides the right number is not in this repository -- `tauri build` fetches linuxdeploy-plugin-gtk from the tip of someone else's branch on every run, so the set copied into the AppDir can change with no commit here, no pull request and no notification. The script intersects what is bundled with the AppImage project's own excludelist and requires the result to equal the strip list exactly, in both directions. It reads that list out of strip-appimage.sh rather than restating it. It runs on the pull request build because that AppImage is the un-stripped one, which for this question is the right artifact rather than a worse one. It only became comparable when #580 moved this job to the release's Ubuntu. `smoke-appimage.sh`, on the release, after the re-sign and before the upload. strip-appimage.sh said a CI smoke test cannot catch this defect because the runner's Mesa is the one the libraries came from -- true of the runner, and only of the runner. A container is another distribution's userspace on the same kernel, which is a host that can disagree. The comment now says so. Liveness is not the check. #499 records that the GTK shell survives while WebKit's WebProcess aborts behind a blank window, so both defects this exists to catch would have passed a "is it still running" test. It greps for the abort, and keeps the liveness check as the backstop for a reworded one. Both scripts also run on pull requests, after a strip, and that is the point rather than thoroughness: smoke-appimage.sh would otherwise reach the release path having never run anywhere, and strip-appimage.sh has never run outside a release -- it failed in two of the three v2.7.2 release attempts. Roughly three minutes on a twelve-minute job. Also, one line in dependabot.yml: the github-actions ecosystem covers `uses:` and not `runs-on:`, so nothing proposes ubuntu-24.04 -> 26.04 and nobody should assume something is watching. Three assertions, each checked by mutation and each failing alone: smoking before the strip, dropping the release smoke, and restating the library list in the new script. 979 pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(ci): report the unbundled half of the strip list rather than failing on it The check's first run found something real and then drew the wrong conclusion from it. Run 31493065830, on the pull request build: Bundled libraries the excludelist says must come from the host: libwayland-client.so.0 strip-appimage.sh removes a library nothing bundles any more: libwayland-cursor.so.0 libwayland-egl.so.1 libwayland-server.so.0 libxcb-render.so.0 libxcb-shm.so.0 Those five are deliberate. #499 named libwayland-client.so.0 as necessary and sufficient and added five more that "belong to the host graphics stack for the same reason and are on the same excludelist" -- prophylaxis against the plugin starting to bundle them, and `rm -f` costs nothing when they are absent. A build not bundling them is not a defect, so it is a notice now. A seventh appearing is still an error, which is the direction that matters. Worth printing, though, because the two builds disagree and nobody knew. In the release, `rm -v` reported all six removed in both v2.7.2 and v2.7.3 -- they were all there. On the pull request's shorter package list, only one is. So the two jobs have been producing different AppImages, and #581's package prune will change what a release bundles rather than being the no-op its own message claimed. The direction is right -- fewer host-coupled libraries is the goal -- but "no behaviour change" was verified against "it builds and produces three bundles", not against the contents. Which difference does it, the package list or the linuxdeploy build.yml pre-downloads, is not isolated. Once both jobs install the same packages, the next release's `removed` lines say. The assertion holding the list to one home now exempts comments, the same way the Ubuntu one does: the new comment names a library while explaining what was measured, and tripped it. 979 pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(ci): give the smoke container the libraries an AppImage expects from a host First real run, on the pull request rather than on a release: host graphics stack: mesa 1:26.1.6-1 Markpad: error while loading shared libraries: libfontconfig.so.1 exit 127 Not the defect this is looking for. An AppImage deliberately does not carry libfontconfig -- it is on the same excludelist as the six strip-appimage.sh removes, and for the same reason -- so it expects the host to have it. A bare archlinux container is not a desktop and does not. fontconfig and a font go in beside xvfb and mesa. And a missing host library now says so, instead of being reported as the app quitting early: the two look identical at exit 127 and mean opposite things. Worth recording that the container's mesa is 1:26.1.6-1, which is the version #498 was reported on. The environment is the failing case, not an approximation of it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(ci): ask the smoke container for GTK, not for one library per round Naming the host's libraries individually is a round of CI each. Run 31494803899 wanted libfontconfig.so.1; with that added, run 31497012965 wanted libfribidi.so.0. There is no reason to think that was the last one. The set is not arbitrary. An AppImage deliberately does not carry these -- they are on the same excludelist as the six strip-appimage.sh removes, and for the same reason -- so what it needs from a host is GTK's own dependency closure, which is exactly what a machine that can run a GTK application has. Installing gtk3 asks for all of it in one go. --------- Co-authored-by: PathGao <gaoyanbo@gaoyanbodeMacBook-Air.local> Co-authored-by: Claude Opus 5 <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
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.
The Node column was unified and has a test holding it there. The Ubuntu column was not, and it is the column that decides which system libraries a binary is linked against.
Nothing chose 22.04
git log -S 'ubuntu-22.04' -- .github/workflows/test_build.ymlreturns exactly one commit: "added test and build workflows", the one that created the file. It has never been revisited.build.ymlhas moved toubuntu-24.04and been maintained there — #499's AppImage strip was written against what noble's linuxdeploy bundles, and #463's WebKitGTK unpin takes the current version fromnoble-updates.What the drift cost
build-testwas answering a question nobody asked. It proves the tree compiles against jammy's libraries. The release compiles against noble's. "The pull request compiled" did not mean "the release will".A pull request's AppImage bundles libraries from a distribution nothing ships. That is the same class of defect as #463 and #498 — an artifact carrying libraries from wherever it happened to be built. It also means a pull request could never have been the place to smoke-test the AppImage, on top of the
--no-signand un-stripped differences.Why this direction and not the other
Releasing from 22.04 is the usual AppImage advice: a binary linked against an older glibc runs on more systems, and 5% of downloads being Linux does not make Linux compatibility worthless.
It is not available here. jammy's WebKitGTK is older than noble's, and older WebKitGTK failing EGL initialisation against current Mesa is exactly what #463 was —
Could not create default EGL display: EGL_BAD_PARAMETER, no window, reported on Arch and reproduced on the v2.7.0 release. The fix was to stop pinning so the build takes 2.52 fromnoble-updates. Releasing from jammy walks back toward the version that failed.Taking the wider-glibc route later means solving #463 a second time, deliberately — bundling a current WebKitGTK rather than inheriting the distribution's. That is a real option and a much larger change than this one.
The assertion
Shaped like the Node one directly above it: the two workflows are compared against each other, never against a literal, so the version does not become a fourth place to update when the runner moves to 26.04.
Checked by mutation — restoring
ubuntu-22.04fails this assertion and nothing else:npm test— 974 pass.Not in this pull request
build.yml'screate-releasejob runs onubuntu-24.04andgenerate-update-feedonubuntu-latest. Neither compiles anything, so neither is part of this fact and neither is asserted.🤖 Generated with Claude Code