ci: fix Werror=comment in kokoro-tts + gate cuda-runtime-validation job#18
Merged
Merged
Conversation
The parity harness calls ggml_backend_cpu_init() and ggml_backend_cpu_set_n_threads() directly. On Android NDK cross-compile the ggml-cpu CMake target is not defined, so the executable was being built with an unresolved link to ggml-cpu, producing: ld.lld: error: undefined symbol: ggml_backend_cpu_init ld.lld: error: undefined symbol: ggml_backend_cpu_set_n_threads Move the entire add_executable + add_test under `if(TARGET ggml-cpu)` so the test is silently skipped on backends without a CPU target, matching how tools/kokoro/CMakeLists.txt already gates kokoro_lib's ggml-cpu link.
tools/omnivoice/CMakeLists.txt bumps GGML_MAX_NAME to 128 PUBLIC on ggml + llama so audio tokenizer tensor names load correctly. That propagates to test-gguf.cpp, where the hand-crafted long-name test case had a hardcoded ~88-char string. Under GGML_MAX_NAME=128 the string was shorter than the limit, the BAD_NAME_SIZE branch failed to actually generate an oversize name, and the in-test sanity assert fired: GGML_ASSERT(name.length() >= GGML_MAX_NAME) failed Append the long suffix in a loop until name strictly exceeds GGML_MAX_NAME, so the oversize-name failure path is always exercised regardless of the GGML_MAX_NAME value the test is compiled with.
cuda-runtime-validation was unconditionally targeted at runners with labels [self-hosted, self-hosted-cuda]. No such runner is registered in the elizaOS org (`gh api repos/elizaOS/llama.cpp/actions/runners` returns total_count: 0), so every push/PR left the job stuck in 'queued' indefinitely — the current PR has been queued for 35+ min, the previous run sat for nearly 2h before being cancelled. This commit: - Adds a `force_cuda_runtime` boolean input on workflow_dispatch. - Gates cuda-runtime-validation behind that input. The job is now skipped on push, PR, and default dispatch runs, and only executes when explicitly forced via `-f force_cuda_runtime=true`. - Keeps ubuntu-cuda-build (Docker-on-ubuntu-24.04 compile validation) running on every push/PR. That job catches CUDA compile/link regressions for the Eliza custom kernels without needing a GPU. - Adds docs/eliza-cuda-runtime-validation.md describing the runner hardware spec (>=24 GB VRAM), GitHub registration steps, cloud provider options (Lambda / RunPod / vast.ai / Paperspace), and the manual trigger command. When a CUDA runner is registered with label 'self-hosted-cuda', trigger the validation with: gh workflow run eliza-cuda-validation.yml -f force_cuda_runtime=true Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The doxygen-style usage banner used trailing backslashes inside `//` comments, which gcc treats as line-continuations and converts the block into a single multi-line comment. With `-Werror=comment` enabled (CI 3rd-party / ubuntu-24-llguidance), this fails: tools/kokoro/tools/kokoro-tts.cpp:6:1: error: multi-line comment Drop the backslashes — they were shell-style continuations that have no meaning in C++ comments anyway. The usage line still reads fine as plain text.
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
github-actions
Bot
added
documentation
This was referenced May 19, 2026
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.
Summary
Two CI follow-up fixes after PR #17.
1.
CI (3rd-party)—-Werror=commentintools/kokoro/tools/kokoro-tts.cppThe usage banner used trailing backslashes inside
//comments, which gcc treats as line-continuations:Drop the backslashes — they were shell-style continuations that have no meaning in C++ comments.
2.
CI (self-hosted)—cuda-runtime-validationjob stuck inqueuedforevercuda-runtime-validationwas unconditionally targeted at[self-hosted, self-hosted-cuda]runners. None are registered in the elizaOS org, so every push left the job hung for hours.force_cuda_runtimeboolean input onworkflow_dispatch.cuda-runtime-validationbehind that input — skipped on push/PR/default dispatch, runs only when forced viagh workflow run eliza-cuda-validation.yml -f force_cuda_runtime=true.ubuntu-cuda-build(Docker compile validation) still runs on every push/PR.docs/eliza-cuda-runtime-validation.mdwith runner spec + manual trigger steps.Test plan