release: ship the engine under its plain name so the archive actually runs#508
Merged
JustVugg merged 1 commit intoJul 21, 2026
devJustVugg/colibri:devfrom
fix/release-package-engine-nameJustVugg/colibri:fix/release-package-engine-nameCopy head branch name to clipboard
Merged
release: ship the engine under its plain name so the archive actually runs#508JustVugg merged 1 commit intodevJustVugg/colibri:devfrom fix/release-package-engine-nameJustVugg/colibri:fix/release-package-engine-nameCopy head branch name to clipboard
JustVugg merged 1 commit into
devJustVugg/colibri:devfrom
fix/release-package-engine-nameJustVugg/colibri:fix/release-package-engine-nameCopy head branch name to clipboard
Conversation
… runs
Download a release archive, unpack it, run `coli chat`, and it says:
engine is not built. Run: coli build
with the engine sitting right there in the same directory.
`coli` locates the engine by looking for "colibri"/"colibri.exe" (then "glm") next to itself,
or $COLI_ENGINE. The Package step copied it in as colibri-<tag>-<platform>[.exe], which
matches none of those, so it fell through to the $PREFIX/libexec layout that does not exist in
an unpacked archive. Every published archive on every platform was affected -- Windows,
Linux and macOS -- and v1.0.0 shipped this way too. Anyone who downloaded a prebuilt binary
and followed the README was told to build from source.
The version belongs in the ARCHIVE name, which is where someone downloading it looks; it does
not belong in the executable that a launcher has to find by name.
Also adds a verification step that unpacks the archive we are about to publish into a clean
directory and asserts `coli` finds the engine. A packaging mistake is invisible to every other
job here -- the build is green, the tests are green, and the artifact is still unusable -- so
this one has to assert on behaviour, not on compilation. Verified locally by reproducing the
Package step: before, "engine is not built"; after, `coli info` runs and `coli chat` reaches
the engine and generates.
The upload glob is now explicit about publishing only archives. It previously worked by
accident, because the versioned engine name did not match `colibri-*.*`.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
pull Bot
pushed a commit
to bryanwills/colibri
that referenced
this pull request
Jul 22, 2026
…me step The README and quickstart still told Windows users to rename the downloaded engine to glm.exe: that was the pre-JustVugg#508 archive layout. Since JustVugg#508 the archive ships the engine plainly named colibri.exe and the launcher finds it with zero setup — the rename step now just confuses people (and the file it names no longer exists). Same sweep for the build docs: 'make glm.exe' is not a target anymore (windows.md recommended it), direct-run examples said ./glm(.exe), metal.md built 'make glm METAL=1'. All now use the real names; troubleshooting rows keep a '(glm.exe pre-rename)' note where old trees are the subject. Co-Authored-By: Claude Fable 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.
Every published release archive is unusable, on every platform, including v1.0.0.
Download it, unpack it, run
coli chat:— with the engine sitting right there in the same directory.
Cause
colilocates the engine by looking forcolibri/colibri.exe(thenglm) next to itself, or$COLI_ENGINE. The Package step copied it in ascolibri-<tag>-<platform>[.exe], which matches none of those, so it fell through to the$PREFIX/libexec/colibrilayout that does not exist in an unpacked archive.So anyone who downloaded a prebuilt binary — the whole point of publishing binaries — was told to build from source.
Fix
The version belongs in the archive name, which is where someone downloading it looks. It does not belong in the executable that a launcher has to find by name.
Reproduced the Package step locally, both ways:
Plus a gate so this cannot happen again
A packaging mistake is invisible to every other job in this repo: the build is green, the tests are green, and the artifact is still broken. Added a step that unpacks the archive we are about to publish into a clean directory and asserts
colifinds the engine — asserting on behaviour, not on compilation.The upload glob is now explicit about publishing only archives; it previously worked by accident, because the versioned engine name happened not to match
colibri-*.*.Note
This should land before the v1.1.0 tag, otherwise v1.1.0 ships the same broken archives.