Skip to content

chore: single-source RAINIX_SHA across reusable workflows - #249

Merged
thedavidmeister merged 2 commits into
mainfrom
chore/single-source-rainix-sha
Jul 3, 2026
Merged

thedavidmeister merged 2 commits into
mainfrom
chore/single-source-rainix-sha

Conversation

@thedavidmeister

@thedavidmeister thedavidmeister commented Jun 29, 2026

Copy link
Copy Markdown
Contributor

Refs #248

What

Adds a top-level env: RAINIX_SHA: to each of the 11 rainix-*.yaml reusable workflow files, then replaces all 35 hardcoded 307bf27fcc5a410994f5a6a6a96527a64625c3da occurrences in run: steps with ${{ env.RAINIX_SHA }}.

Before: SHA appears 35 times across 11 files — a toolchain bump touches 35 lines and a missed occurrence silently drifts.
After: SHA appears once per file (the env.RAINIX_SHA: definition); all run: steps reference the same file-local variable. Bumping means updating 11 env.RAINIX_SHA: lines instead of 35 scattered SHA strings.

Also updates CLAUDE.md to describe the new single-source convention and removes the now-resolved #248 parenthetical.

Test plan

  • check-shell.yml passes (exercises nix flake + dev shell tool availability)
  • test.yml passes (sol + rs tasks against test/fixture/)
  • CI does not directly exercise the reusable workflows on main, but each downstream consumer CI triggers them; the SHA expansion is pure GitHub Actions expression logic with no runtime risk

Summary by CodeRabbit

  • Bug Fixes

    • Standardized workflow setup by using a shared pinned revision value across multiple CI and release jobs, reducing duplicated configuration and keeping builds aligned.
    • Updated several test, packaging, publishing, and artifact-generation steps to reference the same pinned tooling source.
  • Documentation

    • Clarified guidance on how to update the shared pin and added a warning against unpinned references that can cause CI issues.

Adds a top-level env.RAINIX_SHA to each of the 11 rainix-*.yaml reusable
workflow files and replaces the 35 hardcoded sha occurrences with
${{ env.RAINIX_SHA }}. A toolchain bump is now a find-replace of the
env.RAINIX_SHA line across files instead of 35 scattered run: strings.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@thedavidmeister thedavidmeister self-assigned this Jun 29, 2026
@coderabbitai

coderabbitai Bot commented Jun 29, 2026

Copy link
Copy Markdown

Review Change Stack

📝 Walkthrough

Walkthrough

All 11 reusable GitHub Actions workflows replace hardcoded rainlanguage/rainix Nix flake commit SHAs with a workflow-level env.RAINIX_SHA variable, making the pinned revision a single value per file. CLAUDE.md updates the bump procedure documentation accordingly.

Changes

RAINIX_SHA centralization across workflows and docs

Layer / File(s) Summary
rainix-autopublish: env var + all nix develop refs
.github/workflows/rainix-autopublish.yaml
Defines RAINIX_SHA at workflow level and updates all nix develop invocations across cargo/npm/soldeer gates, workspace tests, version bumps, tagging, crates.io/soldeer publish, and GitHub release steps.
All other workflows: env var + nix develop refs
.github/workflows/rainix-copy-artifacts.yaml, .github/workflows/rainix-manual-sol-artifacts.yaml, .github/workflows/rainix-rs-static.yaml, .github/workflows/rainix-rs-test.yaml, .github/workflows/rainix-rs-wasm-test.yaml, .github/workflows/rainix-rs-wasm.yaml, .github/workflows/rainix-sol-legal.yaml, .github/workflows/rainix-sol-static.yaml, .github/workflows/rainix-sol-test.yaml, .github/workflows/rainix-subgraph-test.yaml
Each workflow gains a top-level env.RAINIX_SHA definition and all nix develop github:rainlanguage/rainix/<sha> commands are updated to use ${{ env.RAINIX_SHA }}.
CLAUDE.md: updated bump procedure
CLAUDE.md
Rewrites flake-ref pinning instructions, removes the #248 tracking note, and adds a warning against bare unpinned refs.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~5 minutes

Possibly related PRs

  • rainlanguage/rainix#208: Modifies the same rainix-copy-artifacts.yaml meta regeneration area where this PR parameterizes the flake ref.
  • rainlanguage/rainix#245: Pins the rainix flake to an explicit SHA in rainix-manual-sol-artifacts.yaml, directly preceding the centralization done here.
  • rainlanguage/rainix#247: Introduced the hardcoded per-step SHAs across the same workflows that this PR centralizes into env.RAINIX_SHA.

Poem

🐇 One SHA to rule them all, no more scattered refs to find,
A single env.RAINIX_SHA keeps every workflow aligned.
No more find-replace across eleven files in a rush,
Just change one line and watch the CI flush!
hops away satisfied 🌿

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly and concisely describes the main change: centralizing the RAINIX_SHA pin across reusable workflows.
Linked Issues check ✅ Passed The PR matches #248 by single-sourcing the rainix pin in reusable workflows and updating the related guidance.
Out of Scope Changes check ✅ Passed The changes stay within scope, covering workflow pin refactoring and the accompanying CLAUDE.md documentation update.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch chore/single-source-rainix-sha

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

Comment @coderabbitai help to get the list of available commands.

Co-Authored-By: Claude <noreply@anthropic.com>

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
.github/workflows/rainix-autopublish.yaml (1)

157-164: 🔒 Security & Privacy | 🟠 Major | ⚡ Quick win

Stop interpolating workflow inputs directly into run: scripts.

inputs.npm-package, inputs.level, and inputs.soldeer-package are expanded before bash parses these commands, so a caller can inject shell syntax here and execute arbitrary commands in the release job. Please pass them through env: and validate/quote them before use instead of embedding ${{ inputs.* }} inline.

Also applies to: 238-243, 317-324

🤖 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/rainix-autopublish.yaml around lines 157 - 164, The
workflow step that uses nix develop is interpolating inputs.npm-package inline
in a run script, which allows shell injection in the release job. Move
inputs.npm-package, inputs.level, and inputs.soldeer-package into env for the
affected steps, then reference those env vars inside the bash commands with
proper quoting and any necessary validation. Update the repeated run blocks in
this workflow so the same safe pattern is used consistently instead of embedding
${{ inputs.* }} directly.

Source: Linters/SAST tools

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

Outside diff comments:
In @.github/workflows/rainix-autopublish.yaml:
- Around line 157-164: The workflow step that uses nix develop is interpolating
inputs.npm-package inline in a run script, which allows shell injection in the
release job. Move inputs.npm-package, inputs.level, and inputs.soldeer-package
into env for the affected steps, then reference those env vars inside the bash
commands with proper quoting and any necessary validation. Update the repeated
run blocks in this workflow so the same safe pattern is used consistently
instead of embedding ${{ inputs.* }} directly.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 7c808249-c854-452f-8bf5-9c72ad7c66af

📥 Commits

Reviewing files that changed from the base of the PR and between 69443e7 and bb36eac.

📒 Files selected for processing (12)
  • .github/workflows/rainix-autopublish.yaml
  • .github/workflows/rainix-copy-artifacts.yaml
  • .github/workflows/rainix-manual-sol-artifacts.yaml
  • .github/workflows/rainix-rs-static.yaml
  • .github/workflows/rainix-rs-test.yaml
  • .github/workflows/rainix-rs-wasm-test.yaml
  • .github/workflows/rainix-rs-wasm.yaml
  • .github/workflows/rainix-sol-legal.yaml
  • .github/workflows/rainix-sol-static.yaml
  • .github/workflows/rainix-sol-test.yaml
  • .github/workflows/rainix-subgraph-test.yaml
  • CLAUDE.md

@thedavidmeister
thedavidmeister merged commit 778b350 into main Jul 3, 2026
13 checks passed
@github-actions

github-actions Bot commented Jul 3, 2026

Copy link
Copy Markdown

@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

coderabbitai Bot commented Jul 3, 2026

Copy link
Copy Markdown

Tip

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

SIZE=S

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant