chore(deps): update Mooncake to v0.3.9

[staryxchen]

What

• Dynamically resolve the latest Mooncake version from git tags instead of using a static git clone
• Bump Mooncake version in ATTRIBUTIONS-CPP.md from v0.3.2.post1 to v0.3.9

Why

The previous build script always cloned the default branch of Mooncake, which could lead to version drift and non-reproducible builds. By resolving the version from git tags, we ensure a specific release version is used.

How

• Modified .gitlab/build.sh to use git ls-remote --tags to find the latest Mooncake version tag and clone that specific version
• Updated the attribution file to reflect the new version

This is a clean re-implementation of #1313 on the latest main branch (the original PR had accumulated conflicts).

Summary by CodeRabbit

• Chores

  • Updated Mooncake third-party library to v0.3.9.
  • Build now accepts a Mooncake version from the environment (defaults to v0.3.9), reports the resolved version during acquisition, and checks out that specific release.
  • Updated CI image tag used for Docker-based build and test jobs.

• Documentation

  • Updated Mooncake entry in attributions to v0.3.9.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[github-actions]

👋 Hi staryxchen! Thank you for contributing to ai-dynamo/nixl.

Your PR reviewers will review your contribution then trigger the CI to test your changes.

🚀

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 0f565244-191a-4b46-bc64-15b332d49a18

📥 Commits

Reviewing files that changed from the base of the PR and between a836fb9 and 3706e16.

📒 Files selected for processing (2)

• .ci/jenkins/lib/build-matrix.yaml
• .ci/jenkins/lib/test-matrix.yaml

---

📝 Walkthrough

Walkthrough

The Mooncake version was advanced to v0.3.9. The build script now reads MOONCAKE_VERSION (default v0.3.9), prints it, and clones Mooncake using git clone --depth 1 --branch "${MOONCAKE_VERSION}" .... CI image tag values were updated in two Jenkins matrix files and the attribution header was revised.

Changes

Cohort / File(s)	Summary
Build script .gitlab/build.sh	Adds MOONCAKE_VERSION env-var (default v0.3.9), echoes the resolved value, and uses git clone --depth 1 --branch "${MOONCAKE_VERSION}" to check out the specified branch/tag.
Attributions ATTRIBUTIONS-CPP.md	Updates Mooncake header version from v0.3.2.post1 to v0.3.9.
CI matrices .ci/jenkins/lib/build-matrix.yaml, .ci/jenkins/lib/test-matrix.yaml	Bumps CI_IMAGE_TAG from "20260318-5" to "20260323-1" in both CI matrix files.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

🐰 I hopped to fetch Mooncake, smooth and bright,
Tag set to v0.3.9, hopped into the night.
I read the env, I echoed the line,
Cloned the branch, kept the depth just fine,
🥮 small tweak, big nibble — build’s in sight.

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main change: updating Mooncake from v0.3.2.post1 to v0.3.9. It is concise, specific, and directly reflects the primary purpose of the changeset.
Description check	✅ Passed	The PR description follows the template structure with 'What', 'Why', and 'How' sections. All sections are complete with substantive information about the changes, rationale, and implementation approach.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.gitlab/build.sh:
- Around line 285-286: The build currently sets MOONCAKE_VERSION by querying
remote tags (MOONCAKE_VERSION=$(git ls-remote ...)) which makes builds
non-deterministic; change this to pin the version from ATTRIBUTIONS-CPP.md (set
MOONCAKE_VERSION to the fixed tag v0.3.9), replacing the dynamic git ls-remote
pipeline with a hardcoded assignment and keep the echo "MOONCAKE_VERSION:
${MOONCAKE_VERSION}" line to preserve logging.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 5347de3c-c648-4cf0-9f5a-8eda1b21499d

📥 Commits

Reviewing files that changed from the base of the PR and between 5e2ac5e and 7759385.

📒 Files selected for processing (2)

• .gitlab/build.sh
• ATTRIBUTIONS-CPP.md

[ovidiusm]

Do you know, by any chance, how to tune the number of jobs in mooncake build in a way that does not OOM? Right now mooncake is the only dependency we build with -j4 due to OOM issues when linking. While for everything else we use NPROC.

It's being built by CI on a lot of different machines and -j4 is quite slow. The number of CPUs is high on many of these nodes but memory is limited.

[staryxchen]

Hi @ovidiusm
Thanks for raising this! I'm aware of the -j4 limitation for the Mooncake build — it's indeed quite slow on machines with many cores.

I'll work on optimizing the build parallelism (e.g., using separate job pools for compile vs. link to avoid OOM during linking while keeping compilation fast). My plan is to first push the relevant changes upstream in the Mooncake community, and then contribute the build optimization back here to nixl once that's landed.

[ovidiusm]

/build

[ovidiusm]

/ok to test 32a119a

[ovidiusm]

Please update branch and then update CI_IMAGE_TAG in:

• .ci/jenkins/lib/build-matrix.yaml (line 45)
• .ci/jenkins/lib/test-matrix.yaml (line 33)

[staryxchen]

Hi @ovidiusm, I wasn't sure exactly what "update branch" meant in this context, so I went ahead and rebased onto the latest main. Please let me know if there's anything else needed!

[ovidiusm]

Yes, thanks, please also set CI_IMAGE_TAG to 20260323-1 in the 2 yaml files

[staryxchen]

Done! Updated CI_IMAGE_TAG to 20260323-1 in both files.

[ovidiusm]

/build

[ovidiusm]

/ok to test 3706e16

[staryxchen]

Hey @ovidiusm 👋, following up on your note in this PR about the -j4 bottleneck for Mooncake.

I just landed kvcache-ai/Mooncake#1718 upstream, which adds mooncake-common/limit_jobs.cmake — a memory-aware Ninja job-pool mechanism that automatically separates compile and link parallelism (e.g. compile at full core count, link capped by available memory). It's merged to Mooncake main today but not yet in a stable release.

I've drafted a small patch for nixl (branch feat/mooncake-parallel-build) that achieves the same result at the bash level in .ci/scripts/common.sh + .gitlab/build.sh, so it works regardless of which Mooncake tag nixl pins to:

• Computes MOONCAKE_COMPILE_JOBS / MOONCAKE_LINK_JOBS from available memory (same 1500 MB/compile, 4000 MB/link heuristics as the cmake module), reading cgroup limits in containers and MemAvailable on bare-metal
• Switches the Mooncake cmake step to -G Ninja, replaces make -j4 with cmake --build . -j"${MOONCAKE_LINK_JOBS}"
• Also passes -DPARALLEL_COMPILE_JOBS/-DPARALLEL_LINK_JOBS so once a Mooncake release ships with limit_jobs.cmake, the Ninja job pools kick in automatically with no further changes needed

On a 16-core / 26 GB machine this gives compile=16, link=6 instead of the previous make -j4 for everything.

Question for you: would you prefer to:

1. Go with the bash-level patch now (works with current v0.3.9 and forward-compatible), or
2. Wait until Mooncake cuts a stable release that includes limit_jobs.cmake, then just bump the version and drop a thin cmake include in nixl's Mooncake build step?

Happy to open a PR either way — just wanted to check your preference first!