fix(ci): use cargo install instead of cargo-binstall for anchor-cli

[graveyieldprotocol]

Symptom

Every anchor-build run since PR #15 has failed at the Anchor build step with:

Run set -o pipefail
/home/runner/work/_temp/...sh: line 2: anchor: command not found
Error: Process completed with exit code 127.

The Install Anchor CLI step (cargo-binstall) exited 0, but the anchor binary was never on PATH for the next step.

Root cause

cargo-binstall (cargo-bins/cargo-binstall@main) exited cleanly without installing anchor. Most likely: anchor-cli 0.32.1 has no binstall-compatible prebuilt release pattern that the action's heuristics recognise, and --no-confirm promoted the silent-no-op into a clean exit code rather than an error. The pre-built path that worked under earlier Anchor versions doesn't apply to 0.32.x.

We didn't catch this in PR #14's green CI either because the workflow was different at that time, or because cargo-binstall's heuristics shifted between PR #14 (when it claimed all 5 jobs green) and the post-#15 state.

Fix

Replace cargo-binstall with cargo install --locked --version 0.32.1 anchor-cli plus an explicit anchor --version post-check. This:

• Always installs the anchor binary to ~/.cargo/bin (which dtolnay/rust-toolchain already adds to GITHUB_PATH).
• Surfaces install failures at the install step instead of deferring to the build step.
• Steady-state CI time is unchanged: Swatinem/rust-cache@v2 is already in this job, so subsequent runs hit the cache. Cold runs add ~5-7 min.

Single CI workflow edit. No code changes. No toolchain changes.

Test plan

• CI run on this PR: anchor --version prints 0.32.1 in the install step
• anchor build then proceeds to actual BPF compile (and either passes, or fails for a real reason — in which case the anchor-build-log artifact captures it)
• rust-fmt, rust-clippy, ts-typecheck, terminology-lint remain green (unaffected by this change)

What lands after this

Once green, PR #17 (docs error_codes.md) and the upcoming m5+m6+m7 PRs can land without CI-red gating. The locked security posture requires CodeRabbit + green CI before merge.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Rate limit exceeded

@graveyieldprotocol has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 55 minutes and 4 seconds before requesting another review.

You’ve run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: cee06c91-6aca-4a65-9bf3-7969e1b9482e

📥 Commits

Reviewing files that changed from the base of the PR and between 10a0fa2 and 7569b26.

📒 Files selected for processing (1)

• .github/workflows/ci.yml

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/ci-anchor-install-method

---

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.}