mirror of
https://github.com/logos-co/logos-basecamp.git
synced 2026-08-27 06:41:14 +00:00
Dario LipicarandClaude Opus 5
f57e1692b9
* feat(windows): build and publish a Windows bundle alongside the other platforms
Windows had CI but no downloadable artifact. A release/* push produced an
AppImage per Linux arch and a macOS .app tarball, and nothing a Windows user
could open.
`build-windows` mirrors those jobs: a CROSS build on ubuntu-latest -- nix does
not run on Windows, so there is no Windows runner here; executing the result on
real Windows is what logos-windows-ci's native-smoke leg does. The release job
needs it, downloads it, and attaches artifacts/*-windows.zip.
bin-bundle-dir rather than `default`: it is the same portable directory the
AppImage and .app jobs package, laid out the way the app expects (bin/ +
lib/qt-6/{plugins,qml} + an explicit qt.conf). A PE records no rpath, so that
layout IS the deployment contract.
.zip rather than .tar.gz, because this is the one artifact here whose users are
on Windows, where Explorer opens a zip and nothing opens a tarball.
THE PACKAGING STEP ASSERTS RATHER THAN TRUSTING ITS EXIT CODE. The bundle's DLLs
are symlinks into the nix store, and an archive of dangling links extracts to a
tree that cannot start. nix-bundle-lgx shipped exactly that: `cp -a` implies
--no-dereference, the payload lost 75% of its files, and the step exited 0. So
this copies with -L and then compares the zip's entry count against the bundle's
file count, failing on a shortfall; it also refuses a bundle with no .exe.
The comparison is `<`, not `!=`: a zip counts directory entries too, so a
healthy bundle legitimately produces MORE entries than files. Rehearsed against
a real bundle on an x86_64-linux builder -- 1677 files -> 1768 zip entries,
3 .exe, 0 dangling links after cp -rL, 117 MB.
Named logos-basecamp-x86_64-windows.zip: the full word `windows`, because
logos-release-set's classifier matches on it and a bare `win` would swallow
every darWINd asset.
* ci(windows): drop the disk reclaim -- the runner has 108 GiB, not 14
The step's own justification was the reason to keep it and it does not hold:
"ubuntu-latest ships ~14 GiB free" came from this project's notes, written
before GitHub upgraded the hosted runners. A real run of this workflow reports
/dev/root 145G 37G 108G 26% /
so the step was deleting ~10 GiB from a disk with 108 GiB already free, and
paying ~20 s per job for it.
The Windows job substitutes the mingw closure from the Attic cache rather than
building it, so the build-time store requirement is lower still.
Kept available, not deleted: logos-windows-ci's nix-setup still exposes
free-disk-space, defaulting to false, so a genuinely disk-bound job can opt in.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>