feat(autopublish): one workflow for 1..N crates (workspace publish)

[thedavidmeister]

Generalises rainix-autopublish.yaml from a single crate to a crate list, so one workflow handles single-crate and multi-crate (workspace) repos — no second file.

• New input crates (space-separated, dependency order). The singular crate stays as a back-compat alias (a one-element list), so existing consumers (rain.erc, rain.error, rain.math.float, rain.metadata) keep working unchanged.
• The cargo steps loop over the list: gate per crate (changed if any differs), one cargo release bump of all listed crates in a single commit (atomic inter-crate pin rewrite), publish in dependency order, namespaced <crate>-v<version> tags, one GitHub release per crate.
• npm/soldeer paths unchanged.

Why one workflow, not two: a single crate is just a one-element workspace. This also ends the chained-per-crate-job failure modes on multi-crate repos — rebase conflicts on shared dependent manifests, tag races/collisions — because it's one job, one commit, one push.

Consolidates the fixes from #184/#186/#187/#190 into the workspace-capable form. rain.wasm, rain.metadata, rainlang move to crates:.

Closes #188.

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features

  • Added support for publishing multiple crates in a single workspace release with dependency-ordered publishing.

• Changes

  • Single crate input is now optional; use the new crates input for multi-crate releases.
  • Workspace testing now covers all crates instead of a single crate.
  • Git tags and GitHub Releases are now created per crate.

[coderabbitai]

Caution

Review failed

Pull request was closed or merged during review

📝 Walkthrough

Walkthrough

The autopublish workflow now supports publishing multiple Cargo crates as a unified workspace release. The crate input is optional; a new crates input accepts a space-separated dependency-ordered list. The workflow resolves this list once and uses it throughout change detection, testing, version bumping, tagging, and publishing operations.

Changes

Multi-crate workspace publishing

Layer / File(s)	Summary
Workflow input contract .github/workflows/rainix-autopublish.yaml	crate becomes optional (empty default), new crates input (space-separated dependency-ordered list) added, level input explicitly documents cargo-release behavior with patch default.
Crate list resolution and testing setup .github/workflows/rainix-autopublish.yaml	Resolves final $CRATES variable from inputs.crates or back-compat inputs.crate; Cargo testing switches from single-crate to workspace-wide; initializes hash gate logic with User-Agent and normalization.
Multi-crate change detection and gating .github/workflows/rainix-autopublish.yaml	Change gate loops over $CRATES: packages each crate, normalizes .crate tarball hashes, fetches latest from crates.io, compares hashes, emits single combined changed output.
Multi-crate version bumping and per-crate tagging .github/workflows/rainix-autopublish.yaml	Version bump invokes cargo release once with -p for every crate; after rebase, creates individual <crate>-v<version> tags per crate when changes occurred.
Publishing to crates.io and GitHub Releases .github/workflows/rainix-autopublish.yaml	Publishing updated to loop over $CRATES in dependency order via cargo publish; GitHub Release creation replaced with gh release create loop per crate using <crate>-v<version> tags, with per-crate notes and failure tolerance.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related issues

• rainlanguage/rainix#188: Implements the single combined-job multi-crate publishing behavior requested to avoid chained per-crate push conflicts, with unified workspace-level change detection and a single aggregated change gate flow.

Possibly related PRs

• rainlanguage/rainix#184: Both PRs modify tag and push logic in the same workflow—fix(autopublish): rebase before push so chained release jobs don't race #184 adds rebase-before-push to avoid race failures, while this PR refactors tagging/pushing for per-crate namespace tags across the multi-crate set.

Poem

🐰 A warren of crates to publish as one,
The workflow now loops till the whole job is done,
Tag-by-tag, push-by-push, in dependency order,
No race conditions at the gate's border!
From one crate's constraint to a workspace's care, 🌟

🚥 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 'feat(autopublish): one workflow for 1..N crates (workspace publish)' directly and specifically summarizes the main change: generalizing the autopublish workflow from single-crate to multi-crate (workspace) support.
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-05-26-autopublish-workspace

---

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

[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