feat: add MUSA CICD supports.

[fay85]

Summary

Add compile-only MUSA CI using the same high-level flow as the existing NPU/MLU jobs:

1. check sensitive CI inputs;
2. recursively check out the repository submodules;
3. run the build inside a MUSA compiler image;
4. execute the repository-owned command python setup.py build --device musa.

This revision is limited to three focused files. It does not modify the SMHasher submodule or bundle third-party source snapshots.

File	Purpose
.github/workflows/build_x86_64_musa.yaml	MUSA GitHub Actions workflow
cibuild/build_musa.sh	Host launcher for the MUSA build container
third_party/CMakeLists.txt	MUSA-only target-local compatibility flag for legacy SMHasher code

NPU/MLU alignment

• Uses a self-hosted hardware runner.
• Reuses the runner workspace and .git/modules; removes stale submodule locks, checks out submodules: recursive, and cleans submodule worktrees.
• Reuses a persistent host vcpkg cache, matching the NPU/MLU launcher pattern:
  /export/home/musa_vcpkg_cache:/root/.cache/vcpkg.
• Creates the vcpkg archives and downloads directories on first use; no cache snapshot must be uploaded in advance.
• Runs the normal Python build entry point from the checked-out xLLM revision.
• Uses the existing sensitive-file approval model before executing privileged CI inputs. The MUSA gate additionally verifies a trusted reviewer and the current PR head SHA.

Dependency and image contract

• CI does not consume a vcpkg or third-party source snapshot from the image.
• The launcher ignores image-provided VCPKG_ROOT, DEPENDENCES_ROOT, and related source overrides.
• The repository CMake files select the pinned vcpkg source. Only downloaded files and binary archives are reused from the host cache.
• The image provides the MUSA/Python compiler environment and the container entrypoint. The entrypoint applies the Mooncake MUSA overlay only to the exact expected Mooncake gitlink and restores the submodule on exit.
• The actual build command remains versioned in this repository; it is not hidden in the image.

Validation

Passed:

• bash -n cibuild/build_musa.sh
• YAML parse of .github/workflows/build_x86_64_musa.yaml
• git diff --check
• changed-file scope check: exactly the three files listed above
• the workflow creates /export/home/musa_vcpkg_cache/archives and downloads before the container starts
• the launcher explicitly unsets host/image vcpkg source overrides and directs downloads and binary archives to the mounted host cache
• the fixed image registry.mthreads.com/presale/devtech/xllm:musa-cicd-20260820 was pushed to Harbor and verified (digest sha256:a03d91ad323026b96fe4dac9145302dd534bbee803d314c485a686f102b05030)
• the exact python setup.py build --device musa command was executed with that image; CMake selected mcc_wrapper, and no nvcc was used
• an incremental full build after the fix reached and completed SMHasherSupport (including SpeedTest.o) with -Wno-register

The previous full Python build stopped at third_party/smhasher/src/SpeedTest.cpp:153 because the MUSA compiler promoted SMHasher's legacy C++17 register warning to an error. This is fixed in third_party/CMakeLists.txt with a MUSA-only -Wno-register option scoped to SMHasherSupport; the incremental full build now reaches and completes the SMHasher library.

The same incremental build then exposes separate existing compatibility diagnostics in xllm/core/util/tensor_helper.h (Torch-MUSA source-location API) and cpprest's -Wunused-value checks. Those are outside this focused SMHasher/CI wiring fix and are not masked here.

The image entrypoint applies the bundled Mooncake compatibility overlay only to the pinned dd44a5223a9011cbf37217dcecfe03c3ab01ffdb gitlink and restores the submodule on exit. The MUSA build remains approval-gated for sensitive workflow/launcher changes and will run after a trusted reviewer approves the exact current head.

Review focus

Please review the three-file CI contract, especially recursive submodule traceability, the host vcpkg cache mount, the sensitive-input approval gate, and graceful container cleanup.

[yinjiawei01]

Since third_party is sourced from /opt/xllm-third_party in the image instead of the repository submodules, changes to third_party revisions in the PR won't be reflected in MUSA CI. Could we make the bundled third-party revisions traceable to the xLLM revision being tested?

[fay85]

Agreed this was a real gap. The runner cannot submodules: recursive because gitcode is unreachable, so CI still seeds third_party from /opt/xllm-third_party in the image. The seed is now stamped in-tree at cibuild/musa/third_party_seed.txt (xLLM 6f702778 / CICD-build-0813), and cibuild/musa/_build_cuda_graph_musa.sh logs git ls-tree gitlinks next to that stamp so a mismatch is visible in the job log. Bumping submodule revisions still requires rebuilding the image; we cannot fetch those repos from this runner.

[yinjiawei01]

The actual build script comes from /opt/xllm-musa-build/_build_cuda_graph_musa.sh inside the image, so the build logic is no longer tied to the xLLM commit. Could we put the build commands directly in the workflow instead, so that the build logic is versioned together with the xLLM code?

[fay85]

Moved the build logic into the xLLM tree. cibuild/build_musa.sh only pulls/runs the image; cibuild/musa/_build_cuda_graph_musa.sh (cmake + ninja, no setup.py), ninja/link wrappers, and clang/mcc overlays under cibuild/musa-compat/ are invoked from the checkout so they version with the commit. The image stays the compiler / vcpkg / third_party snapshot.