feat(ci): add support for aarch64-unknown-linux-musl target#3077
feat(ci): add support for aarch64-unknown-linux-musl target#3077YufJi wants to merge 11 commits intozeroclaw-labs:masterfrom
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
Note
|
| Cohort / File(s) | Summary |
|---|---|
GitHub Actions workflows .github/workflows/release-beta-on-push.yml, .github/workflows/release-stable-manual.yml |
Added aarch64-unknown-linux-musl matrix entry with use_zigbuild: true; added conditional Install cargo-zigbuild step (installs zig and cargo-zigbuild); modified Build release step to run cargo zigbuild --release --locked --target when use_zigbuild is true, otherwise preserve previous cargo build flow (including optional linker env export). |
Estimated code review effort
🎯 3 (Moderate) | ⏱️ ~20 minutes
Suggested labels
size: XS, ci
Suggested reviewers
- JordanTheJet
- chumyin
🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
| Check name | Status | Explanation |
|---|---|---|
| Title check | ✅ Passed | The title clearly and concisely summarizes the main change: adding aarch64-unknown-linux-musl target support via zigbuild integration in CI workflows. |
| Description check | ✅ Passed | The PR description addresses all required template sections with substantive content, including validation evidence with screenshots, security analysis, and comprehensive metadata. |
| 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
- Post copyable unit tests in a comment
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 @coderabbitai help to get the list of available commands and usage tips.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/release.yml:
- Around line 88-92: Update the PR notes and docs/actions-source-policy.md to
document that the release workflow step named "Install cargo-zigbuild" now pulls
from PyPI (via the command pip3 install ziglang) and crates.io (via cargo
install cargo-zigbuild); add allowlist entries for PyPI and crates.io, include
the exact commands/packagenames (ziglang and cargo-zigbuild) and a short
justification so reviewers can audit these new external sources.
- Around line 88-92: The "Install cargo-zigbuild" step currently installs
floating releases; update that step to pin both Zig and cargo-zigbuild by
specifying exact versions (replace "pip3 install ziglang" with a pinned package
version like "pip3 install ziglang==<ZIG_VERSION>" or the project's chosen
installer/token) and install cargo-zigbuild with a pinned crate version and the
--locked flag (replace "cargo install cargo-zigbuild" with "cargo install
cargo-zigbuild --version <CARGO_ZIGBUILD_VERSION> --locked"); keep the
conditional matrix.use_zigbuild and ensure the chosen version strings are added
as workflow inputs or constants so they can be updated reproducibly.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: c001bc92-1eae-4886-bf61-f2de3335dc60
📒 Files selected for processing (1)
.github/workflows/release.yml
chore(ci): pin ziglang and cargo-zigbuild to exact versions in release workflow (#1) chore: update ziglang and cargo-zigbuild versions in release workflow
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.github/workflows/release.yml (1)
88-92: Add--lockedflag tocargo installfor consistency with other build steps.The version pins are correct and verified. However, this install step should also use
--lockedto match the reproducibility approach used in the main build commands (lines 98 and 103), ensuring the tool's own lockfile is honored:Suggested change
- name: Install cargo-zigbuild if: matrix.use_zigbuild run: | pip3 install ziglang==0.15.2 - cargo install cargo-zigbuild --version 0.22.1 + cargo install cargo-zigbuild --version 0.22.1 --locked🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release.yml around lines 88 - 92, The workflow step named "Install cargo-zigbuild" uses `cargo install cargo-zigbuild --version 0.22.1` without the --locked flag; update that command to include --locked so the install honors Cargo.lock for reproducible builds (i.e., change the `cargo install cargo-zigbuild --version 0.22.1` invocation in the "Install cargo-zigbuild" step to add --locked).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In @.github/workflows/release.yml:
- Around line 88-92: The workflow step named "Install cargo-zigbuild" uses
`cargo install cargo-zigbuild --version 0.22.1` without the --locked flag;
update that command to include --locked so the install honors Cargo.lock for
reproducible builds (i.e., change the `cargo install cargo-zigbuild --version
0.22.1` invocation in the "Install cargo-zigbuild" step to add --locked).
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: e6a1319b-8cee-4f22-be7a-baaee55e7f5b
📒 Files selected for processing (1)
.github/workflows/release.yml
There was a problem hiding this comment.
🧹 Nitpick comments (2)
.github/workflows/release-beta-on-push.yml (1)
88-92: Make the Zig tool bootstrap deterministic.Same concern as in the stable workflow: this relies on the runner’s default Python and on
cargo installwithout--locked. GitHub recommends usingsetup-pythonto make the interpreter explicit, and Cargo only uses the published lockfile for installs when--lockedis passed. Tightening both would make the beta musl lane more reproducible. (docs.github.com)Proposed hardening
+ - uses: actions/setup-python@v5 + if: matrix.use_zigbuild + with: + python-version: '3.12' + - name: Install cargo-zigbuild if: matrix.use_zigbuild run: | - pip3 install ziglang==0.15.2 - cargo install cargo-zigbuild --version 0.22.1 + python -m pip install ziglang==0.15.2 + cargo install --locked cargo-zigbuild --version 0.22.1🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release-beta-on-push.yml around lines 88 - 92, Update the "Install cargo-zigbuild" step to make the Zig bootstrap deterministic: use the actions/setup-python action to pin the Python interpreter instead of calling pip3 directly (refer to the step name "Install cargo-zigbuild" and condition "matrix.use_zigbuild"), and invoke cargo install for "cargo-zigbuild" with the --locked flag (the current command is "cargo install cargo-zigbuild --version 0.22.1") so Cargo respects the lockfile; ensure the step runs the explicit setup-python action before running the pip install and cargo install commands..github/workflows/release-stable-manual.yml (1)
106-110: Make the Zig tool bootstrap deterministic.This step still depends on runner-image defaults in two places: GitHub recommends
setup-pythonwhen a workflow needs Python because the hosted runner’s default Python can change, and Cargo ignores a package’s published lockfile unlesscargo install --lockedis used. Pinning a Python version and adding--lockedhere would make this musl job much less likely to break because of image drift or transitive dependency churn. (docs.github.com)Proposed hardening
+ - uses: actions/setup-python@v5 + if: matrix.use_zigbuild + with: + python-version: '3.12' + - name: Install cargo-zigbuild if: matrix.use_zigbuild run: | - pip3 install ziglang==0.15.2 - cargo install cargo-zigbuild --version 0.22.1 + python -m pip install ziglang==0.15.2 + cargo install --locked cargo-zigbuild --version 0.22.1🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release-stable-manual.yml around lines 106 - 110, Update the "Install cargo-zigbuild" step to make the Zig bootstrap deterministic: add a prior call to actions/setup-python to pin a specific Python version (e.g., 3.x) instead of relying on the runner default so the pip3 install ziglang==0.15.2 is deterministic, and change the cargo install invocation (the cargo install cargo-zigbuild --version 0.22.1 command) to include --locked so Cargo respects the published lockfile and avoids transitive dependency drift.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In @.github/workflows/release-beta-on-push.yml:
- Around line 88-92: Update the "Install cargo-zigbuild" step to make the Zig
bootstrap deterministic: use the actions/setup-python action to pin the Python
interpreter instead of calling pip3 directly (refer to the step name "Install
cargo-zigbuild" and condition "matrix.use_zigbuild"), and invoke cargo install
for "cargo-zigbuild" with the --locked flag (the current command is "cargo
install cargo-zigbuild --version 0.22.1") so Cargo respects the lockfile; ensure
the step runs the explicit setup-python action before running the pip install
and cargo install commands.
In @.github/workflows/release-stable-manual.yml:
- Around line 106-110: Update the "Install cargo-zigbuild" step to make the Zig
bootstrap deterministic: add a prior call to actions/setup-python to pin a
specific Python version (e.g., 3.x) instead of relying on the runner default so
the pip3 install ziglang==0.15.2 is deterministic, and change the cargo install
invocation (the cargo install cargo-zigbuild --version 0.22.1 command) to
include --locked so Cargo respects the published lockfile and avoids transitive
dependency drift.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 93a10e41-780c-415b-8e76-515fb6912dfb
📒 Files selected for processing (2)
.github/workflows/release-beta-on-push.yml.github/workflows/release-stable-manual.yml
rareba
left a comment
There was a problem hiding this comment.
Core implementation is sound — the zigbuild approach is standard for musl cross-compilation, versions are pinned, and existing targets are untouched. One required change:
Required: Update docs/contributing/actions-source-policy.md
This PR introduces two new supply-chain surfaces into the release pipeline:
- PyPI:
ziglang==0.15.2 - crates.io:
cargo-zigbuild==0.22.1
Per the guardrails in actions-source-policy.md, these should be documented in this PR, not deferred.
Suggested (non-blocking):
- Add
--lockedtocargo install cargo-zigbuild --version 0.22.1for full transitive dependency reproducibility - Consider
actions/setup-python@v5before the pip install step (currently relies on implicit runner Python)
The build logic branching is clean, both workflows are kept in sync, and no existing targets are affected.
|
Quick fix list to get this merged: Required: Update
|
Summary
masteraarch64-unknown-linux-muslmatrix entry was misconfigured, leaving no release asset available for devices such as OpenWrt-based routersuse_zigbuild: true; added an install step forcargo-zigbuild+ziglang; updated the build step to branch onuse_zigbuildx86_64-unknown-linux-gnu,aarch64-unknown-linux-gnu,aarch64-apple-darwin,x86_64-pc-windows-msvc) are untouchedLabel Snapshot (required)
risk: lowsize: XSciChange Metadata
featureciLinked Issue
Supersede Attribution (required when
Supersedes #is used)N/A
Validation Evidence (required)
forked repo's action built successfully:
validated target
aarch64-unknown-linux-muslasset worked on my router:Security Impact (required)
pip3 install ziglang(PyPI) andcargo install cargo-zigbuild(crates.io), scoped to the musl build job only; both are standard CI dependency installation patternsYes, describe risk and mitigation: Both packages are well-known public packages; versions can be pinned in a follow-up PR if stricter supply-chain control is requiredPrivacy and Data Hygiene (required)
passCompatibility / Migration
Side Effects / Blast Radius (required)
aarch64-unknown-linux-muslmatrix job inrelease.ymlbuild stage onlycargo install cargo-zigbuildadds ~1–2 min to the musl job; all other target jobs are unaffectedfail-fast: falseis already set — a musl job failure will not cancel other platform buildsRollback Plan (required)
git revert <commit>to restorerelease.ymlto the pre-change state; no stateful dependenciescargo-zigbuild: command not foundorpip install ziglangerrorRisks and Mitigations
None
Summary by CodeRabbit