fix(release): repair all build targets in the Release workflow - #42
Merged
Conversation
The v0.17.2 Release run failed on every target. Three independent root
causes, each fixed here:
1. Empty-string backend env vars were treated as "set". The CI matrix
passes `GGML_VULKAN: ${{ matrix.vulkan && 'ON' || '' }}`, exporting the
var as "" on non-Vulkan targets. `is_explicitly_set` used
`env::var().is_ok()`, so "" counted as set and the CPU and macOS builds
tried to link the ggml-vulkan / vulkan libraries absent from their
prebuilt archives. Now empty/whitespace counts as unset.
Fixes: Linux-x86_64 (CPU), macOS-arm64.
2. The prebuilt Vulkan target never installed libvulkan-dev. The
"Install Vulkan SDK" step was gated on `!matrix.prebuilt`, but that
target uses a prebuilt archive, so the step was skipped and the linker
could not resolve -lvulkan. Install libvulkan-dev whenever matrix.vulkan.
Fixes: Linux-x86_64-vulkan.
3. The llama.cpp submodule was stale. It was pinned to 0ccbfde
(2026-02-14), far behind the b9837 release that the bridge code and
prebuilt libraries target (b3fed31, 2026-06-28). The from-source
CUDA/SYCL builds compiled autocommit_common_bridge.cpp against the old
`common` API and failed on missing symbols (common_download_opts,
common_params_speculative::draft, common_grammar, ...). Repin to
b3fed31 (tag b9837).
Fixes: Linux-x86_64-cuda, Linux-x86_64-sycl.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR repairs the failing Release workflow across all build matrix targets by aligning build-time backend selection and system dependencies with the project’s standardized llama.cpp b9837 release.
Changes:
- Update
llama-sysbuild logic to treat empty backend env vars as “unset” (prevents unintended Vulkan linking on CPU/macOS builds). - Ensure the Vulkan Release job installs
libvulkan-deveven when using prebuilt llama.cpp artifacts.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| crates/llama-sys/build.rs | Adjusts backend env-var detection to ignore empty values (avoids accidental Vulkan link flags / prebuilt selection). |
| .github/workflows/release.yml | Installs Vulkan loader link dependency (libvulkan-dev) whenever the Vulkan matrix target is selected. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
99
to
101
| fn is_explicitly_set(var: &str) -> bool { | ||
| env::var(var).is_ok() | ||
| env::var(var).is_ok_and(|v| !v.trim().is_empty()) | ||
| } |
SnowCheetos
added a commit
that referenced
this pull request
Jul 8, 2026
The b9837 submodule bump (#42) resolved the bridge API drift, but the from-source CUDA and SYCL release targets then failed at 3% with: app/llama.cpp:1:10: fatal error: build-info.h: No such file or directory b9837 introduced two new CMake targets — LLAMA_BUILD_APP (the "unified binary") and LLAMA_BUILD_UI — both defaulting ON for a standalone (top-level) build. build.rs disables TESTS/EXAMPLES/TOOLS/SERVER but not these, so cmake tried to build app/llama.cpp, which needs a generated build-info.h and breaks the library-only build we need for FFI. Pass -DLLAMA_BUILD_APP=OFF and -DLLAMA_BUILD_UI=OFF. Verified against a b9837 checkout: with these flags the app subdirectory is no longer configured and libllama/ggml/common build cleanly. Only affects the from-source backends (CUDA/SYCL); prebuilt targets (CPU/Vulkan/macOS) never run the cmake source build. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
SnowCheetos
added a commit
that referenced
this pull request
Jul 8, 2026
…pile (#44) * ci(release): publish built artifacts even when some targets fail The `release` job used `needs: build` with no `if:`, so a single failed matrix leg (currently the slow CUDA/SYCL source builds) skipped the whole release — discarding the CPU, Vulkan, and macOS binaries that built fine minutes earlier. Add `if: ${{ !cancelled() }}` so the release job runs after the build matrix regardless of individual failures, publishing whatever artifacts were uploaded. Failed legs upload nothing and are simply absent from the release. If every target failed (zero artifacts) the job errors instead of cutting an empty release. The overall run still goes red when a target fails, keeping the failure visible. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(build): no-op llama_params_fit in the from-source build After pinning the submodule to b9837 (#42), the CUDA and SYCL source builds compiled the full tree (~15 min) and then failed: autocommit_common_bridge.cpp:662: error: 'llama_params_fit' was not declared in this scope The bridge guarded llama_params_fit behind `#ifdef LLAMA_CPP_PREBUILT`, no-oping it for the binary release but still calling it from source. b9837 does not expose that public symbol in either mode — the fitting logic moved into libcommon's internal common/fit.cpp. Drop the source branch and no-op unconditionally, matching the prebuilt backends that already ship. Verified: the bridge compiles against b9837 in both modes (with and without -DLLAMA_CPP_PREBUILT). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * docs(release): clarify why the release job uses !cancelled() not always() Addresses review feedback. !cancelled() does run when a needs leg fails (including a status function overrides Actions' implicit success() gate) and, unlike always(), still skips a manually cancelled run. No behavior change. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <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
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.
Overview
The
v0.17.2Release workflow (run 28777992467) failed on every target. There were three independent root causes; this PR fixes all of them. Each fix aligns the build on the singleb9837llama.cpp release the project already standardizes on.Failure map
Linux-x86_64(CPU)unable to find library -lggml-vulkan/-lvulkanmacOS-arm64ld: library 'ggml-vulkan' not foundLinux-x86_64-vulkanunable to find library -lvulkanlibvulkan-devLinux-x86_64-cudacommon_download_opts/.draftnot declaredLinux-x86_64-syclcommon_grammar/COMMON_GRAMMAR_TYPE_USERnot declaredChanges
①
crates/llama-sys/build.rs— treat empty env var as unset.The release matrix passes
GGML_VULKAN: ${{ matrix.vulkan && 'ON' || '' }}, which exports the variable as an empty (but present) string on non-Vulkan targets.is_explicitly_setusedenv::var(var).is_ok(), so""counted as "set" — the CPU and macOS builds then selected the Vulkan archive libs / emitted-lvulkan, which their prebuilt archives don't contain. Nowis_explicitly_setrequires a non-empty value.②
.github/workflows/release.yml— installlibvulkan-devfor the Vulkan target.The "Install Vulkan SDK" step was gated
if: matrix.vulkan && !matrix.prebuilt, but the Vulkan target uses a prebuilt archive, so the step was skipped andlibvulkan.so(the unversioned link symlink for-lvulkan) was never installed. Now gated onif: matrix.vulkan.③
third_party/llama.cpp— repin submodule tob9837.The submodule was pinned to
0ccbfde(2026-02-14), months behind theb9837release (b3fed31, 2026-06-28) thatautocommit_common_bridge.cppand the prebuilt libraries target. The from-source CUDA/SYCL builds compiled the bridge against the stalecommonAPI and failed on missing symbols. Repinned0ccbfde → b3fed31so source builds match the bridge and the prebuilt-based targets.Validation
CI is the real test here (native GPU toolchains + per-target runners). Logic verified by hand:
b9837tag resolves to commitb3fed31, and itscommon.hcontains the symbols the source builds were missing.libggml-vulkan.sobut links the system Vulkan loader, solibvulkan-devis genuinely required at link time.Not in this PR (follow-up)
Separately, prebuilt/dynamic installs (
cargo install, and the released Linux/macOS tarballs) fail at runtime withlibllama.so.0: cannot open shared object file— the baked rpath points at the build tree, and only the binary is relocated. The durable fix is an$ORIGIN/@loader_path-relative rpath plus a README correction; happy to send that as a separate PR.