fix: update release and rust workflows

[broccolingual]

No description provided.

[gemini-code-assist]

Note

Gemini is unable to generate a summary for this pull request due to the file types involved not being currently supported.

[Copilot]

Pull request overview

Updates the GitHub Actions workflows for Rust CI and crate releases, aiming to improve caching and automate crates.io publishing based on version tags.

Changes:

• Adjust Rust CI workflow checkout action version and add a cache restore-keys fallback.
• Replace the manual release workflow with a tag-triggered flow that bumps Cargo.toml and runs cargo publish.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

File	Description
.github/workflows/rust.yml	Updates checkout action version and improves Cargo cache restore behavior.
.github/workflows/release.yml	Switches release triggering to tag pushes and automates version bump + crates.io publish.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The steps: list items appear to be indented at the same level as steps: itself, which makes the workflow YAML invalid (GitHub Actions expects the - uses / - name entries to be nested under steps). Indent all step entries (including this checkout step) two spaces further than steps: so the workflow can parse and run.

[Copilot]

This workflow is triggered by pushing a tag, but it checks out main and then publishes from whatever is currently on main. That can publish code that does not correspond to the tagged commit (e.g., if the tag was created from an older commit or main advanced), which breaks the expectation that a tag identifies the exact source being released. Consider checking out the tag ref/sha that triggered the workflow for the publish step, and avoid mutating main as part of the tag-triggered release (or at least fail the job if the tag commit is not main HEAD).

Suggested change

	with:
	ref: main
	- name: Ensure tag matches main HEAD
	run: |
	git fetch origin main
	TAG_SHA="$(git rev-parse HEAD)"
	MAIN_SHA="$(git rev-parse origin/main)"
	if [ "$TAG_SHA" != "$MAIN_SHA" ]; then
	echo "Tag commit ($TAG_SHA) does not match origin/main HEAD ($MAIN_SHA). Aborting release."
	exit 1
	fi

[Copilot]

The commit message includes [skip ci], but the Rust workflow is configured to run on every push to main and does not have any condition that honors this marker. As a result, this version-bump commit will still trigger CI, and the message is misleading. Either remove [skip ci] from the message or add an explicit condition in the relevant workflows to skip when the commit message contains that token.

Suggested change

	git commit -m "chore: bump version to $VERSION [skip ci]"
	git commit -m "chore: bump version to $VERSION"

[Copilot]

The release job runs cargo publish without explicitly installing/pinning a Rust toolchain (it relies on whatever happens to be preinstalled on ubuntu-latest). This can lead to non-reproducible releases or unexpected breakage when the runner image changes. Add an explicit Rust toolchain setup step (or a checked-in toolchain file) so the publish environment is deterministic.

[Copilot]

on.push.tags uses glob patterns, not regular expressions. The pattern v[0-9]+.[0-9]+.[0-9]+ will only match tags that literally contain + characters (e.g., v1+.2+.3+), so a normal SemVer tag like v1.2.3 will not trigger this workflow. Use a glob that matches SemVer tags (e.g., v*.*.*) or a supported pattern that doesn’t rely on + regex quantifiers.

Suggested change

	- 'v[0-9]+.[0-9]+.[0-9]+'
	- 'v*.*.*'