fix(ci): pin rainix flake rev in deploy reusable to avoid api.github.com 429

[thedavidmeister]

Problem

nix develop github:rainlanguage/rainix#sol-shell resolves the flake's HEAD via https://api.github.com/repos/rainlanguage/rainix/commits/HEAD. Under CI bursts GitHub burst/secondary rate-limits that call (429) — and once authenticated it returns a gzip-compressed rate-limit body that nix-2.24.12 fails to decompress, surfacing as json.exception.parse_error.101 … invalid literal … '<U+001F>'. This has been the recurring org-wide nix CI flake.

Auth does not fix it. Verified directly: setting access-tokens via NIX_CONFIG does apply the token (nix config show lists it), but the commits/HEAD fetch still fails — it's a burst limit, not a missing credential.

Fix

Pin the flake refs to a full commit sha. With an explicit rev, nix skips the commits/HEAD api.github.com resolution entirely and pulls the tarball directly (codeload, far higher limits). Pins all three nix develop calls in the deploy reusable to 307bf27fcc5a410994f5a6a6a96527a64625c3da (current main).

Confirmed

A deploy run on this branch got past every flake-fetch step (forge soldeer install, forge selectors up, into forge script Deploy) with zero 429/gzip errors — it now reaches the actual deploy logic. (It stops at an unrelated base-RPC dependency check.)

Notes

• This pins the deploy toolchain to 307bf27f; bump the sha when the rainix toolchain changes. For a deploy reusable a stable, pinned toolchain is desirable (reproducible deploys).
• The same pin should roll to the other reusables (rainix-sol-test, rainix-rs-test, etc.) for the full org-wide 429 fix — follow-up, weighed against wanting CI to track the current toolchain.

🤖 Generated with Claude Code

Summary by CodeRabbit

• Chores
  • Updated deployment workflow steps to use a fixed Rainix source reference for more consistent artifact builds and verification.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 1caf97d7-1bfe-48f9-a1f4-3c173888f8a8

📥 Commits

Reviewing files that changed from the base of the PR and between 307bf27 and 8c4d333.

📒 Files selected for processing (1)

• .github/workflows/rainix-manual-sol-artifacts.yaml

---

📝 Walkthrough

Walkthrough

Three nix develop invocations in the manual sol artifacts workflow's deploy job are updated to reference a pinned Rainix commit hash instead of the unpinned github:rainlanguage/rainix#sol-shell ref.

Changes

Pin Rainix ref in CI workflow

Layer / File(s)	Summary
Pin nix develop ref in forge steps .github/workflows/rainix-manual-sol-artifacts.yaml	The nix develop calls for forge soldeer install, forge selectors up --all, and forge script Deploy now use a pinned commit hash ref instead of the unpinned Rainix repository ref.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Poem

A bunny pinned the Nix ref tight,
No floating commits lost in night.
Soldeer, selectors, deploy with glee,
All locked to one commit's decree.
🐇 Stability for you and me!

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: pinning the rainix flake revision in the deploy reusable to prevent GitHub API 429 errors.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/pin-rainix-flake

---

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

[thedavidmeister]

Reviewed 8c4d333: pins the deploy reusable's three nix develop github:rainlanguage/rainix#sol-shell refs to a full sha, so nix skips the api.github.com commits/HEAD resolution that GitHub burst-rate-limits (429 / gzipped body nix mis-parses). Confirmed working — a deploy run on this branch ran clean through every flake-fetch step (forge soldeer install, forge selectors up, into forge script Deploy), zero 429s.

Merge explicitly authorized by thedavidmeister ("merge 245") — this is his approval, not an agent self-approval.

CI: the only failing checks are the two rainix-check-shell jobs at nix flake check --impure, which evaluates flake.nix — a file this 3-line deploy-reusable change does not touch — so they are pre-existing and structurally unrelated (check-shell has its own unpinned flake fetch). All relevant checks pass (rainix-sol-artifacts, forge test/fmt, cargo build/test, slither, reuse lint). Merging.

[github-actions]

@coderabbitai assess this PR size classification for the totality of the PR with the following criterias and report it in your comment:

S/M/L PR Classification Guidelines:

This guide helps classify merged pull requests by effort and complexity rather than just line count. The goal is to assess the difficulty and scope of changes after they have been completed.

Small (S)

Characteristics:

• Simple bug fixes, typos, or minor refactoring
• Single-purpose changes affecting 1-2 files
• Documentation updates
• Configuration tweaks
• Changes that require minimal context to review

Review Effort: Would have taken 5-10 minutes

Examples:

• Fix typo in variable name
• Update README with new instructions
• Adjust configuration values
• Simple one-line bug fixes
• Import statement cleanup

Medium (M)

Characteristics:

• Feature additions or enhancements
• Refactoring that touches multiple files but maintains existing behavior
• Breaking changes with backward compatibility
• Changes requiring some domain knowledge to review

Review Effort: Would have taken 15-30 minutes

Examples:

• Add new feature or component
• Refactor common utility functions
• Update dependencies with minor breaking changes
• Add new component with tests
• Performance optimizations
• More complex bug fixes

Large (L)

Characteristics:

• Major feature implementations
• Breaking changes or API redesigns
• Complex refactoring across multiple modules
• New architectural patterns or significant design changes
• Changes requiring deep context and multiple review rounds

Review Effort: Would have taken 45+ minutes

Examples:

• Complete new feature with frontend/backend changes
• Protocol upgrades or breaking changes
• Major architectural refactoring
• Framework or technology upgrades

Additional Factors to Consider

When deciding between sizes, also consider:

• Test coverage impact: More comprehensive test changes lean toward larger classification
• Risk level: Changes to critical systems bump up a size category
• Team familiarity: Novel patterns or technologies increase complexity

Notes:

• the assessment must be for the totality of the PR, that means comparing the base branch to the last commit of the PR
• the assessment output must be exactly one of: S, M or L (single-line comment) in format of: SIZE={S/M/L}
• do not include any additional text, only the size classification
• your assessment comment must not include tips or additional sections
• do NOT tag me or anyone else on your comment

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

SIZE=S