Skip to content

test_fixtures: publish to crates.io in the lockstep release set - #529

Merged
thedavidmeister merged 1 commit into
mainfrom
2026-06-07-publish-test-fixtures
Jun 7, 2026
Merged

test_fixtures: publish to crates.io in the lockstep release set#529
thedavidmeister merged 1 commit into
mainfrom
2026-06-07-publish-test-fixtures

Conversation

@thedavidmeister

@thedavidmeister thedavidmeister commented Jun 7, 2026

Copy link
Copy Markdown
Contributor

Why

rainlang_test_fixtures has been git-only (publish = false since its init commit). It's a leaf test-fixtures crate consumed only by raindex, via a git rev pin — and it's the last git dependency blocking raindex's move to a fully crates.io / soldeer dependency tree (raindex #2593; the root git deps and submodules there are already done).

Publishing it — rather than vendoring a copy into raindex — keeps the fixtures version-aligned with the same DISPAIR + parser bytecode they wrap, which lives in rainlang_bindings/rainlang_parser (already in this lockstep set, and which raindex pins as "the same rainlang rev family"). Vendoring would split a member out of that family and reintroduce drift.

Change

  • crates/test_fixtures/Cargo.toml: drop publish = false, add version = "0.1.0" + description (matches the rainlang_bindings metadata shape; license/homepage/edition already inherit from the workspace).
  • package-release.yaml: append rainlang_test_fixtures to the lockstep crates: list. It depends on none of the other members (only alloy + getrandom, both crates.io), so it's appended last.

Effect of merging

The autopublish workflow detects the new/changed crate and bumps the entire lockstep set one patch, republishing rainlang_bindings/rainlang_dispair/rainlang_parser/rainlang-eval at +1 and publishing rainlang_test_fixtures for the first time. That family-wide bump is expected lockstep behavior.

Publish-readiness verified: the dependency closure is crates.io-clean (alloy = "1.0.9", no git deps), and the sibling crates already publish from this workspace.

Follow-up (separate raindex PR, after this publishes): swap raindex's crates/test_fixtures git dep to the published rainlang_test_fixtures version, closing #2593.

Summary by CodeRabbit

  • Chores
    • Test fixtures crate is now published alongside core packages in the release workflow.

rainlang_test_fixtures has been git-only (publish = false since its init
commit). It's a leaf test-fixtures crate consumed by raindex via a git rev
pin — the last git dependency blocking raindex's move to a fully crates.io /
soldeer dependency tree (raindex #2593).

Make it publishable and add it to the lockstep release set so it stays
version-aligned with the bindings/dispair/parser bytecode it wraps:
- drop `publish = false`, add version + description metadata
- append `rainlang_test_fixtures` to package-release.yaml's crate list

Merging this triggers the autopublish workflow, which bumps the whole
lockstep set a patch and publishes (including the first rainlang_test_fixtures).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@thedavidmeister thedavidmeister self-assigned this Jun 7, 2026
@coderabbitai

coderabbitai Bot commented Jun 7, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

📝 Walkthrough

Walkthrough

The PR enables automated publication of the rainlang_test_fixtures crate by removing the publish = false flag from its manifest, adding version and description metadata, and registering it in the package release workflow's lockstep autopublish pipeline.

Changes

Enable test_fixtures crate publication

Layer / File(s) Summary
Crate manifest preparation
crates/test_fixtures/Cargo.toml
Cargo manifest adds explicit version (0.1.0) and description fields for local EVM test fixtures; publish = false is removed while workspace-inherited edition, license, and homepage metadata remain unchanged.
Release workflow integration
.github/workflows/package-release.yaml
Package release workflow's crates input list and inline dependency-order comments are updated to include rainlang_test_fixtures in the lockstep autopublish set; the crate depends on none of the others but remains version-pinned with the release.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Possibly related issues

  • rainlanguage/rainlang#519: Directly addresses the task to drop publish = false from test_fixtures and enable its publication in the release workflow.

Possibly related PRs

  • rainlanguage/rainlang#516: Both PRs update the same package-release.yaml lockstep release configuration by adding an additional crate to the automated publication pipeline.

Poem

🐰 A fixture finds its place to play,
No longer hidden, bound and gray—
With version, description, workflow's care,
The test tools dance in public air! ✨

🚥 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 clearly summarizes the main change: making test_fixtures publishable to crates.io as part of the lockstep release set.
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.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch 2026-06-07-publish-test-fixtures

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 and usage tips.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Actionable comments posted: 1

🤖 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/package-release.yaml:
- Line 13: Update the reusable workflow reference to pin it to the immutable
commit SHA instead of the mutable branch: replace the uses value "uses:
rainlanguage/rainix/.github/workflows/rainix-autopublish.yaml@main" with the
same path suffixed by the commit SHA "c5b581af819cddbbd18a2eadbc2754782f49d4b0"
so the workflow is invoked as "uses:
rainlanguage/rainix/.github/workflows/rainix-autopublish.yaml@c5b581af819cddbbd18a2eadbc2754782f49d4b0".
🪄 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: CHILL

Plan: Pro

Run ID: e2949866-7a91-4b7f-b8c1-195a2b7d35b1

📥 Commits

Reviewing files that changed from the base of the PR and between 7d1dfc4 and 7e39ad8.

📒 Files selected for processing (2)
  • .github/workflows/package-release.yaml
  • crates/test_fixtures/Cargo.toml

# changing any member republishes the others with matching version pins, via
# the PUBLISH_PRIVATE_KEY deploy key. test_fixtures depends on none of the
# others but is released in lockstep so its embedded bytecode stays in sync.
uses: rainlanguage/rainix/.github/workflows/rainix-autopublish.yaml@main

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Verify current SHA behind main before pinning.
gh api repos/rainlanguage/rainix/commits/main --jq '.sha'

Repository: rainlanguage/rainlang

Length of output: 106


Pin the reusable workflow to an immutable commit SHA.

@main is mutable; pin rainix-autopublish.yaml to the current upstream main commit (c5b581af819cddbbd18a2eadbc2754782f49d4b0) to strengthen supply-chain integrity.

Suggested change
-    uses: rainlanguage/rainix/.github/workflows/rainix-autopublish.yaml@main
+    uses: rainlanguage/rainix/.github/workflows/rainix-autopublish.yaml@c5b581af819cddbbd18a2eadbc2754782f49d4b0
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
uses: rainlanguage/rainix/.github/workflows/rainix-autopublish.yaml@main
uses: rainlanguage/rainix/.github/workflows/rainix-autopublish.yaml@c5b581af819cddbbd18a2eadbc2754782f49d4b0
🧰 Tools
🪛 zizmor (1.25.2)

[error] 13-13: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[warning] 13-13: secrets unconditionally inherited by called workflow (secrets-inherit): this reusable workflow

(secrets-inherit)

🤖 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/package-release.yaml at line 13, Update the reusable
workflow reference to pin it to the immutable commit SHA instead of the mutable
branch: replace the uses value "uses:
rainlanguage/rainix/.github/workflows/rainix-autopublish.yaml@main" with the
same path suffixed by the commit SHA "c5b581af819cddbbd18a2eadbc2754782f49d4b0"
so the workflow is invoked as "uses:
rainlanguage/rainix/.github/workflows/rainix-autopublish.yaml@c5b581af819cddbbd18a2eadbc2754782f49d4b0".

Source: Linters/SAST tools

@thedavidmeister

Copy link
Copy Markdown
Contributor Author

Reviewed 7e39ad8: metadata (version + description) and lockstep crates: addition are correct; dependency closure is crates.io-clean (alloy 1.0.9, no git deps); all CI green. Approve — merging triggers the lockstep patch bump + first publish of rainlang_test_fixtures.

@thedavidmeister
thedavidmeister merged commit b034759 into main Jun 7, 2026
8 checks passed
@github-actions

github-actions Bot commented Jun 7, 2026

Copy link
Copy Markdown
Contributor

@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 Jun 7, 2026

Copy link
Copy Markdown
Contributor

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