ci: add create-release workflow and fix crates.io publish

[Christiantyemele]

What this adds

1. create-release.yml — One-click release automation

A new GitHub Actions workflow that can be triggered manually from the Actions tab:

• Go to Actions → Create Release
• Enter the version (e.g., v1.1.6)
• Check "Mark as pre-release?" if needed
• Click Run workflow

It will automatically:

1. Bump the version in binary/Cargo.toml
2. Commit and push to main
3. Create and push the git tag (e.g., v1.1.6)
4. Create a GitHub Release (or pre-release)

The existing release.yml then picks up the tag and builds binaries for all platforms.

2. Fix for release.yml — crates.io publish tolerance

The publish-crates job now loops through crates and continues on failure instead of crashing the entire release when a crate already exists on crates.io. This was the error that blocked the v0.1.6 release pipeline:
cargo publish -p pocketflow-core --token *** → error: crate pocketflow-core@0.1.0 already exists

[gitar-bot]

Code Review ⚠️ Changes requested 0 resolved / 1 findings

Automates the release workflow and improves crates.io publish stability by allowing partial success, but both workflows currently attempt to create the GitHub Release, leading to conflicts.

⚠️ Bug: create-release and release.yml both create the GitHub Release

📄 .github/workflows/release.yml:279-289

create-release.yml pushes the v* tag (step "Create and push tag") and then itself creates a GitHub Release via softprops/action-gh-release. However, release.yml is triggered by pushes of v* tags and also creates a GitHub Release for the same tag (release.yml:279-289). The two workflows race to create/update the same release.

Consequences: (1) create-release publishes the release immediately with no built binaries attached, then release.yml later builds and re-uploads to the same release — the auto-generated notes / pre-release body written by create-release may be overwritten by release.yml. (2) The pre-release/stable flag is decided independently in each workflow (create-release uses the prerelease input; release.yml derives is_prerelease from its own resolve-version logic), so the final prerelease flag can disagree with the user's intent. Consider having create-release only bump+tag and let release.yml own release creation, or explicitly coordinate the prerelease flag and release-notes ownership between them.

🤖 Prompt for agents

Code Review: Automates the release workflow and improves crates.io publish stability by allowing partial success, but both workflows currently attempt to create the GitHub Release, leading to conflicts.

1. ⚠️ Bug: create-release and release.yml both create the GitHub Release
   Files: .github/workflows/release.yml:279-289

   create-release.yml pushes the `v*` tag (step "Create and push tag") and then itself creates a GitHub Release via softprops/action-gh-release. However, release.yml is triggered by pushes of `v*` tags and also creates a GitHub Release for the same tag (release.yml:279-289). The two workflows race to create/update the same release.
   
   Consequences: (1) create-release publishes the release immediately with no built binaries attached, then release.yml later builds and re-uploads to the same release — the auto-generated notes / pre-release body written by create-release may be overwritten by release.yml. (2) The pre-release/stable flag is decided independently in each workflow (create-release uses the `prerelease` input; release.yml derives `is_prerelease` from its own resolve-version logic), so the final prerelease flag can disagree with the user's intent. Consider having create-release only bump+tag and let release.yml own release creation, or explicitly coordinate the prerelease flag and release-notes ownership between them.

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

---

Important

Your trial ends in 3 days — upgrade now to keep code review, CI analysis, auto-apply, custom automations, and more.

_{Was this helpful? React with 👍 / 👎 | Gitar}

[github-actions]

[logic] (confidence: 85%)

The workflow bumps the version in binary/Cargo.toml but does not update Cargo.lock to match. In a Cargo workspace, the lockfile contains the version of each workspace member, so after changing the version in Cargo.toml, Cargo.lock must also be regenerated (e.g., via cargo generate-lockfile). The commit only stages binary/Cargo.toml, leaving Cargo.lock stale with the old version number.

Impact: The tagged commit will have an inconsistent workspace where Cargo.toml says 1.1.6 but Cargo.lock still references the old version. Any subsequent cargo build --locked or cargo check --locked on that commit will fail with a lockfile mismatch error. This also means the repository state on main is inconsistent after the workflow runs, until someone manually regenerates the lockfile.

Evidence:

sed -i "s/^version = \".*\"/version = \"${VERSION_NUM}\"/" binary/Cargo.toml
...
git add binary/Cargo.toml
git commit -m "release: bump version to ${VERSION}"

Suggestion: After the sed command, run cargo generate-lockfile (or cargo check) to update Cargo.lock, then also git add Cargo.lock before committing.

[github-actions]

Snif Review

Adds a manual create-release GitHub Actions workflow that bumps the version in binary/Cargo.toml, commits, tags, and creates a GitHub release; also modifies the existing release workflow to tolerate already-published crates during cargo publish by continuing on failure instead of aborting.

Found 1 issue. See inline comments for details.

Review details

Changed files:

• .github/workflows/create-release.yml
• .github/workflows/release.yml
• Cargo.lock
• binary/Cargo.toml

Context analyzed: 90 related files (90 via keyword matching).

Stats: 155 lines | glm-5p1 | 23s

[Christiantyemele]

Also addresses the review on PR #123 (#123 (comment)): the openflows binary crate was missing from the publish loop. It's already included in this PR's version of release.yml (line 339).