Gate the full-set artifact on failure and add the keep_artifacts hatch (

#11)

CI: ccache the SD CUDA leg (#9)

* CI: ccache the SD CUDA leg

This leg rebuilt every object on every run. It took 3903 s of the 4121 s job on
2026-08-09 and 4942 s on the run before it, with no speedup between the two,
while every other job in the pipeline finished in under 8 minutes. The repo held
no cache entry for it at all, only the ROCm ones build.yml writes.

Key on the CUDA version and the architecture list, since both decide the
objects, and set the CUDA compiler launcher as well as C and CXX: nvcc is nearly
the whole build and Jimver installs it outside the default search. Save on
always() so a failed or capped job keeps what it compiled.

* CI: do not fail the CUDA build on a ccache stats call

CI: build the prebuilts from this repository, not from a fetched tarb…

…all (#8)

* CI: build the prebuilts from this repository, not from a fetched tarball

The pipeline resolved an upstream release tag, fetched that tree, applied
the patch set in patches/, and built the result. That made every
published binary depend on a foreign repository at build time and left
three fixes living as diffs that had to be kept applying to a tree we do
not control.

All three are already commits here, merged as PRs 2, 3 and 4. So build
this checkout. patches/ is deleted; there is nothing left to re-apply.

The tag still names the upstream release the tree descends from, read
from our own history rather than from an API, with the head sha as the
-u suffix:

    master-813-bfbef5b-u22e2879

Two details worth keeping.

HIGHEST reachable release, not nearest. git describe answers "nearest",
and on a merge-shaped history that is wrong: this tree reaches
master-813 through a merge 73 commits back and master-811 on its own
line 13 commits back, so describe names the build after 811 and
understates what it contains.

The -u suffix is now always present, which is what it should have been.
Studio's installer treats a -u tag as mirror-only and goes straight to
this repository's releases instead of trying an upstream download that
is guaranteed to 404. A build of ours is never a stock upstream build,
so it should never carry a bare upstream tag.

Supply-chain aging is kept and re-pointed: it now guards the age of the
upstream release the tree descends from rather than the moment a
release appeared. Our own commits on top are reviewed here, so they are
not what the delay is for.

assemble_metadata keeps its --patches flag, always empty, so existing
manifest readers do not have to change.

* CI: carry pinned PRs into the prebuilts, like unslothai/llama.cpp does

The prebuilts now build this tree, but that alone only ships what is
already merged. The llama.cpp pipeline exists to ship a reviewed mix:
an aged upstream base plus a set of pull requests pinned to exact
commits, merged at build time. This adds the same mechanism here.

scripts/unsloth/pr-set.json lists PRs to merge, each pinned to a
40-hex commit copied from the PR's commits tab. Only that commit is
built, so an author pushing more commits cannot change what the
nightly ships. Non-open required pins fail the build rather than
silently publishing without them, because dropping a pin changes the
tag and would ship a quietly different binary under a new name.
additive_merge.py, vendored from unslothai/llama.cpp, resolves the one
conflict shape that is mechanical (both sides only added, at a place
the merge base had nothing) and refuses to guess at anything else.

One deliberate difference from llama.cpp. There the base is a pristine
upstream release, so every Unsloth change has to stay pinned and open,
and merging one into fork master drops it from the nightly. Here the
base is our own tree, so a merged fix is simply in it and its pin is
deleted. That is why the three MiniMax-H3 fixes need no pins.

Only PRs in this repository may be pinned. To carry a fix that exists
as an upstream pull request, vendor it here as a PR first and pin
that. The build fetches from nowhere else.

The tag suffix absorbs the set: with no pins it is the head sha, with
pins it hashes the pinned number:sha pairs together with the head sha,
so a repin or a reorder yields a new tag and a rebuild while an
unchanged set still matches an existing release and skips. The
existing -u shape is kept rather than llama.cpp's -mix-, because
Studio's installer keys mirror-only resolution on it.

Verified locally against this tree: the schema gate passes, an empty
set yields master-813-bfbef5b-u692a7c8, a one-pin set yields a
different suffix, and both match the installer's mirror-only pattern.

* CI: publish a Linux CUDA prebuilt

The CPU/Apple matrix rests on the assumption that a GPU host runs the
diffusers path instead. MiniMax-H3 breaks that assumption: its diffusers
path wants ~68.5 GB of VRAM, so every consumer card falls back to the
GGUF engine, and on Linux that engine had no accelerated build to fall
back to. Measured on one box, 65 s/step at 320x192 across 96 CPU
threads, against 21.5 s/step at 960x544 from a local CUDA build of the
same tag: four hours per clip versus eleven minutes.

The new leg is continue-on-error and is not in the coverage gate, which
still lists exactly the five CPU/Apple assets. assemble collects bundles
by the sd-*-bin-* pattern, so the CUDA asset is published when it built
and simply absent when it did not; a broken CUDA toolchain can never
hold back the assets Studio falls back to.

sm_75 through sm_120, which is the first toolkit able to emit sm_100 and
sm_120 and covers everything from Turing up. The CUDA runtime libraries
are copied in beside the binaries with an $ORIGIN rpath, because a host
with an NVIDIA driver does not necessarily have a CUDA runtime installed
and we must not lean on the copies torch keeps.

package_bundle matched runtime libraries on Path.suffix, which reads
".12" for libcudart.so.12 and dropped it. It now matches the ".so."
infix as well, so a versioned soname ships under the exact name
DT_NEEDED spells.

* CI: name the cuBLAS packages the way apt does

cuda-toolkit installs sub-packages as cuda-<name>-12-8, and cuBLAS does not use
that prefix, so apt could not find cuda-cublas-12-8 or cuda-cublas_dev-12-8 and
the leg died before it compiled anything. They belong in non-cuda-sub-packages
as libcublas and libcublas-dev. cudart-dev joins the list too, since cudart on
its own is the runtime and carries no headers to compile against.

The libcublas debs land in the system multiarch directory rather than under the
toolkit root, so the bundling step now searches both.

Apply the open H3 fixes to the prebuilts we publish

The prebuilt pipeline builds leejet's source at an aged release tag, not this
fork's master, so the three MiniMax-H3 fixes on master reach nobody: every
Studio user installs a binary that still aborts on the default cfg-scale, still
aborts on --vae-on-cpu, and still quantizes H3's 1-D norms into an output
uncorrelated with its own bf16 reference.

Building from master instead would throw away the reason the pipeline is shaped
this way, which is that what we publish should be traceable to a specific
upstream release. So keep the upstream tag as the base and carry the delta
explicitly:

- patches/ holds one file per fix, each with its upstream pull request in the
  header. All three are open on leejet: leejet#1861, leejet#1862, leejet#1863.
- resolve applies them to the checked-out tag, after running git apply --check
  over the whole set so a stale patch stops the run before the tree is half
  modified. That failure is the signal to delete the patch (upstream merged it)
  or refresh it (upstream moved the code).
- a non-empty set moves the published tag to <upstream tag>-u<id>, where id is
  the sha256 prefix of the concatenated patches. The tag then says whether a box
  is stock, and a changed patch set republishes rather than matching an existing
  release and skipping.
- the manifest and the release notes both record the applied list.

An empty patches/ leaves the tag and every asset name exactly as they are today.

Verified by running the resolve step against master-813-bfbef5b with gh stubbed:
all three patches apply, the tag becomes master-813-bfbef5b-u<id>, and the
stamped source tarball contains the fixes.

Pass /bigobj to the Windows CPU prebuilt build

stable-diffusion.cpp grew past MSVC's default object section limit on the
newer upstream tags (fatal error C1128 in run 28701743849); upstream's own
Windows CI passes -DCMAKE_CXX_FLAGS='/bigobj' for the same reason.

Pass /bigobj to the Windows CPU prebuilt build

stable-diffusion.cpp grew past MSVC's default object section limit on the
newer upstream tags (fatal error C1128 in run 28701743849); upstream's own
Windows CI passes -DCMAKE_CXX_FLAGS='/bigobj' for the same reason.

Pass /bigobj to the Windows CPU prebuilt build

stable-diffusion.cpp grew past MSVC's default object section limit on the
newer upstream tags (fatal error C1128 in run 28701743849); upstream's own
Windows CI passes -DCMAKE_CXX_FLAGS='/bigobj' for the same reason.

Pass /bigobj to the Windows CPU prebuilt build

stable-diffusion.cpp grew past MSVC's default object section limit on the
newer upstream tags (fatal error C1128 in run 28701743849); upstream's own
Windows CI passes -DCMAKE_CXX_FLAGS='/bigobj' for the same reason.

Pass /bigobj to the Windows CPU prebuilt build

stable-diffusion.cpp grew past MSVC's default object section limit on the
newer upstream tags (fatal error C1128 in run 28701743849); upstream's own
Windows CI passes -DCMAKE_CXX_FLAGS='/bigobj' for the same reason.

Pass /bigobj to the Windows CPU prebuilt build

stable-diffusion.cpp grew past MSVC's default object section limit on the
newer upstream tags (fatal error C1128 in run 28701743849); upstream's own
Windows CI passes -DCMAKE_CXX_FLAGS='/bigobj' for the same reason.