koboldcpp/ci
Jan Ekström a6d6183dbc
ggml-vulkan/CMakeLists: add a check for SPIRV-Headers (#22009)
* ci/run: set explicit SPIR-V Headers search path for macOS vulkan CI

For whatever reason, the files are under additional sub-path
`vulkan/` under the cmake directory, which does not match either
current LunarG macOS Vulkan SDK structure (`lib/cmake/SPIRV-Headers`),
nor what gets installed when you run the cmake build+install for
SPIRV-Headers itself on at least Linux (`share/cmake/SPIRV-Headers`).

This allows for SPIRV-Headers to be found, as currently the CI
runner's setup does not seem to include the relevant path in
list of search locations.

* ggml-vulkan/CMakeLists: add a check for SPIRV-Headers

This is installed by the project if it is built and installed.
Receiving an error during the configuration step is generally
preferred to receiving an error in the middle of a build.
2026-05-17 13:12:11 +02:00
..
README-MUSA.md musa: upgrade musa sdk to 4.3.0 (#16240) 2025-09-26 02:56:38 +02:00
README.md ci : migrate ggml ci to self-hosted runners (#16116) 2025-09-21 16:50:45 +03:00
run.sh ggml-vulkan/CMakeLists: add a check for SPIRV-Headers (#22009) 2026-05-17 13:12:11 +02:00

CI

This CI implements heavy-duty workflows that run on self-hosted runners. Typically the purpose of these workflows is to cover hardware configurations that are not available from Github-hosted runners and/or require more computational resource than normally available.

It is a good practice, before publishing changes to execute the full CI locally on your machine. For example:

mkdir tmp

# CPU-only build
bash ./ci/run.sh ./tmp/results ./tmp/mnt

# with CUDA support
GG_BUILD_CUDA=1 bash ./ci/run.sh ./tmp/results ./tmp/mnt

# with SYCL support
source /opt/intel/oneapi/setvars.sh
GG_BUILD_SYCL=1 bash ./ci/run.sh ./tmp/results ./tmp/mnt

# with MUSA support
GG_BUILD_MUSA=1 bash ./ci/run.sh ./tmp/results ./tmp/mnt

# etc.

Adding self-hosted runners

  • Add a self-hosted ggml-ci workflow to .github/workflows/build.yml with an appropriate label
  • Request a runner token from ggml-org (for example, via a comment in the PR or email)
  • Set-up a machine using the received token (docs)
  • Optionally update ci/run.sh to build and run on the target platform by gating the implementation with a GG_BUILD_... env