ci: add a macOS build+test job for contributor portability#824
Conversation
Every workflow runs ubuntu-22.04 only. Add a lean macos-latest job that builds and tests the workspace (protoc via Homebrew) so OS-specific breakage (paths, mmap/MDBX, time, endianness) surfaces in CI before it reaches a contributor's Mac. Kept separate from the Linux `test` job — the lint/deny/secret-scan steps there are platform-agnostic, and a separate job leaves the existing `Test` check name untouched. Validators run Linux/docker only, so this is a portability signal, not a production target.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
📝 WalkthroughWalkthroughA new Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/ci.yml:
- Around line 109-113: The Build step runs cargo build without the --release
flag, which places compiled binaries in target/debug/, but the job later uploads
artifacts from target/release/ paths. This mismatch causes missing release
artifacts. Add the --release flag to the cargo build --workspace command to
ensure binaries are compiled in release mode and placed in the target/release/
directory that matches the upload paths.
- Line 101: The `actions/cache` action reference on line 101 uses a mutable tag
(v5) instead of a pinned commit SHA, which violates the strict workflow
integrity policy. Replace the `uses: actions/cache@v5` statement with a
reference to a full commit SHA (get the SHA for the v5 release from the
actions/cache repository), and add a comment noting the tag version (e.g., # v5)
for readability, following the same pattern already applied to
`dtolnay/rust-toolchain` earlier in the workflow file.
- Line 92: In the checkout action step, replace the unpinned
`actions/checkout@v5` tag with a pinned commit SHA to match the repo's security
practices (consistent with line 95), and add `persist-credentials: false` since
no authenticated git operations occur later in the job. Additionally, in the
cargo build step, change `cargo build --workspace` to `cargo build --workspace
--release` to ensure the binary is built in release mode, matching the release
artifact paths (`target/release/sentrix` and `target/release/sentrix-faucet`)
referenced in the subsequent upload steps.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 557ba402-05a1-4b80-9f87-fb268ff2f3fa
📒 Files selected for processing (1)
.github/workflows/ci.yml
| name: Test (macOS) | ||
| runs-on: macos-latest | ||
| steps: | ||
| - uses: actions/checkout@v5 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/ci.yml | sed -n '80,115p'Repository: sentrix-labs/sentrix
Length of output: 1518
🏁 Script executed:
cat -n .github/workflows/ci.yml | sed -n '115,135p'Repository: sentrix-labs/sentrix
Length of output: 1116
🏁 Script executed:
rg 'uses: actions/(checkout|cache|upload-artifact)@' .github/workflows/ci.ymlRepository: sentrix-labs/sentrix
Length of output: 375
Pin checkout action to commit SHA, disable credential persistence, and fix build profile mismatch.
Line 92 uses unpinned actions/checkout@v5 (a moving tag) and keeps default credential persistence. This contradicts the repo's own practice of pinning actions to commit SHAs (see line 95). Pin to a commit SHA and set persist-credentials: false since no authenticated git operations occur later in the job.
Additionally, line 110 builds with cargo build --workspace (debug profile), but lines 120 and 128 attempt to upload release artifacts (target/release/sentrix and target/release/sentrix-faucet). This mismatch will cause artifact uploads to fail silently on main pushes. Change line 110 to cargo build --workspace --release.
Suggested patches
- - uses: actions/checkout@v5
+ - uses: actions/checkout@<commit_sha>
+ with:
+ persist-credentials: false - name: Build
- run: cargo build --workspace
+ run: cargo build --workspace --release🧰 Tools
🪛 zizmor (1.25.2)
[warning] 92-92: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 92-92: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/ci.yml at line 92, In the checkout action step, replace
the unpinned `actions/checkout@v5` tag with a pinned commit SHA to match the
repo's security practices (consistent with line 95), and add
`persist-credentials: false` since no authenticated git operations occur later
in the job. Additionally, in the cargo build step, change `cargo build
--workspace` to `cargo build --workspace --release` to ensure the binary is
built in release mode, matching the release artifact paths
(`target/release/sentrix` and `target/release/sentrix-faucet`) referenced in the
subsequent upload steps.
Source: Linters/SAST tools
| run: brew install protobuf | ||
|
|
||
| - name: Cache cargo | ||
| uses: actions/cache@v5 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Check if the workflow file exists and read it
if [ -f .github/workflows/ci.yml ]; then
echo "=== File exists, reading content ==="
wc -l .github/workflows/ci.yml
echo "=== Content around line 101 ==="
sed -n '95,110p' .github/workflows/ci.yml
else
echo "File not found"
fiRepository: sentrix-labs/sentrix
Length of output: 650
🌐 Web query:
GitHub Actions security best practices pinning commit SHA vs tag version references
💡 Result:
Pinning GitHub Actions to a full-length commit SHA is the recommended security best practice for ensuring the integrity and immutability of your CI/CD pipelines [1][2][3]. The fundamental distinction lies in mutability: - Commit SHA (Immutable): A full-length commit SHA refers to a specific, unique snapshot of the action's code [4][5][6]. Once a commit is created, its content cannot change, providing a guarantee that your workflow will execute the exact same code every time it runs [4][6]. - Tags (Mutable): Git tags (e.g., v1, v4.2.1) are merely pointers [7]. A repository maintainer—or a malicious actor who compromises the repository—can move a tag at any time to point to a different commit [7][8][4]. Using tags introduces a supply chain risk where your pipeline could silently execute different, potentially malicious code without any change to your workflow file [7][4][5]. Security Recommendations: 1. Pin to Full SHA: Always use the full-length commit SHA for third-party actions to prevent "retargeting" attacks [1][2]. 2. Maintain Readability: To keep workflows maintainable, include the original tag version as a comment next to the SHA [7][6][9]. Example: uses: actions/checkout@a84108e4... # v4.1.0 [1][7] 3. Use Automated Tools: Use tools like Dependabot, Renovate, or specialized CLI tools (e.g., pin-github-action, ratchet, or zizmor) to manage these pins, automate updates, and ensure you remain on secure versions while minimizing the manual maintenance burden [7][5][10][6]. 4. Organizational Policy: GitHub allows administrators to enforce full commit SHA pinning at the organization or repository level [11][2][9]. When enabled, any workflow referencing an action by a tag will fail, ensuring compliance across your infrastructure [4][9]. 5. Trust and Verification: While SHA pinning is the primary technical control, it does not replace the need for supply chain hygiene [8]. Always verify that the SHA belongs to the legitimate upstream repository and not a fork [1][3][10]. Organizations should prioritize SHA pinning as part of a broader "secure by default" strategy, acknowledging that while tags offer convenience for local or internal development, they are inadequate for high-assurance, production-grade workflows [2][3][6].
Citations:
- 1: https://codeql.github.com/codeql-query-help/actions/actions-unpinned-tag/
- 2: https://docs.github.com/en/actions/reference/security/secure-use
- 3: https://github.com/github/docs/blob/962a1c8dccb8c0f66548b324e5b921b5e4fbc3d6/content/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions.md
- 4: https://www.romainlespinasse.dev/posts/github-actions-commit-sha-pinning/
- 5: https://www.cncf.io/blog/2026/05/04/securing-github-actions-ci-dependencies-recipe-card/
- 6: https://www.stepsecurity.io/blog/pinning-github-actions-for-enhanced-security-a-complete-guide
- 7: https://safeguard.sh/resources/blog/github-actions-pinning-sha-vs-tag
- 8: https://emmer.dev/blog/pin-your-github-actions-to-protect-against-mutability/
- 9: https://dev.to/nicolasv/github-actions-why-you-should-pin-your-actions-to-a-specific-version-1513
- 10: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/GitHub_Actions_Security_Cheat_Sheet.md
- 11: https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/
Pin actions/cache to a full commit SHA.
Line 101 references actions/cache@v5 by tag, which is mutable. Pinning to a commit SHA is required to satisfy strict workflow integrity policy and prevent supply-chain drift. The repository already pins dtolnay/rust-toolchain to a commit SHA (line 95); apply the same pattern here by including the tag as a comment for readability.
Suggested patch
- name: Cache cargo
uses: actions/cache@<full_commit_sha> # v5
with:🧰 Tools
🪛 zizmor (1.25.2)
[error] 101-101: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/ci.yml at line 101, The `actions/cache` action reference
on line 101 uses a mutable tag (v5) instead of a pinned commit SHA, which
violates the strict workflow integrity policy. Replace the `uses:
actions/cache@v5` statement with a reference to a full commit SHA (get the SHA
for the v5 release from the actions/cache repository), and add a comment noting
the tag version (e.g., # v5) for readability, following the same pattern already
applied to `dtolnay/rust-toolchain` earlier in the workflow file.
Source: Linters/SAST tools
| - name: Build | ||
| run: cargo build --workspace | ||
|
|
||
| - name: Test | ||
| run: cargo test --workspace |
There was a problem hiding this comment.
Build profile is inconsistent with release artifact upload paths.
Line 110 builds without --release, but this job later uploads binaries from target/release/.... That mismatch can yield missing/empty release artifacts on main pushes. Build in release mode here (or update upload paths intentionally).
Suggested patch
- name: Build
- run: cargo build --workspace
+ run: cargo build --workspace --release🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/ci.yml around lines 109 - 113, The Build step runs cargo
build without the --release flag, which places compiled binaries in
target/debug/, but the job later uploads artifacts from target/release/ paths.
This mismatch causes missing release artifacts. Add the --release flag to the
cargo build --workspace command to ensure binaries are compiled in release mode
and placed in the target/release/ directory that matches the upload paths.
1 participant
Adds a lean
macos-latestjob (build + test, protoc via Homebrew) alongside the Linuxtestjob. All 17 workflows were ubuntu-only; this catches macOS-specific breakage (paths, mmap/MDBX, time, endianness) for contributors who develop on a Mac.Kept as a separate job rather than matrix-ifying
testso the existingTestcheck name stays stable (no branch-protection churn) and the platform-agnostic lint/deny/secret-scan steps don't get duplicated on the slower macOS runner.Validators run Linux/docker only, so this is a contributor-portability signal, not a production target. Suggest letting it bake green before promoting
Test (macOS)to a required check.Summary by CodeRabbit