feat: enhance release workflow with cherry-pick version sync to main

[frontegg-david]

Summary by CodeRabbit

• Chores

  • Released version 2.11.0 across all packages
  • Updated internal package dependency references for consistent versions

• New Features

  • Improved release automation: stable releases are now automatically proposed to the main branch via an automated PR (falling back to issue creation with manual guidance if propagation fails)
  • Publish workflow now exposes version, prerelease, and branch outputs for downstream steps

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds outputs to the publish job and a new cherry-pick-version-to-main GitHub Actions job that conditionally cherry-picks the version-bump commit to the default branch (creating a PR on success or an issue on conflict). Also bumps multiple library package versions from 2.10.0 → 2.11.0.

Changes

Cohort / File(s)	Summary
Workflow Automation ​.github/workflows/publish-release.yml	Adds outputs (version, is_prerelease, branch) to publish and introduces cherry-pick-version-to-main job that runs after publish (when not a dry run and not a prerelease). Job checks latest semver, attempts cherry-pick of version-bump onto default branch, creates PR on success or creates an issue on conflict.
Package Version Bumps (minor) libs/ast/package.json, libs/types/package.json	Bumps package versions from 2.10.0 → 2.11.0.
Package Version & Dependency Bumps (internal) libs/broker/package.json, libs/client/package.json, libs/core/package.json, libs/react/package.json, libs/runtime/package.json, libs/stream/package.json	Bumps package versions from 2.10.0 → 2.11.0 and updates internal cross-package dependency versions to 2.11.0 where applicable.

Sequence Diagram(s)

sequenceDiagram
    participant GH as GitHub Actions
    participant Git as Git Repository
    participant API as GitHub API

    GH->>GH: publish job completes\noutputs: version, is_prerelease, branch
    alt not dry run & not prerelease
        GH->>Git: checkout + fetch tags
        GH->>Git: determine latest stable semver
        alt released version is latest
            GH->>Git: configure git credentials
            GH->>Git: locate version-bump commit on release branch
            GH->>Git: create cherry-pick branch from default branch
            GH->>Git: attempt cherry-pick of version-bump
            alt cherry-pick succeeds
                GH->>Git: commit & push cherry-pick branch
                GH->>API: create PR with labels and body
                API-->>GH: PR created
            else cherry-pick conflicts
                GH->>Git: abort cherry-pick
                GH->>API: create issue with manual guidance
                API-->>GH: Issue created
            end
        end
    end

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related PRs

• chore: update dependencies and improve security in code execution (#49) #51: Similar package manifest updates across libs/* (version/dependency bumps).
• feat: enhance security by neutralizing dangerous Object methods and adding prototype escape tests #52: Overlaps in package version updates and release workflow adjustments.

Poem

🐰 I hopped through tags and tiny things,
I nudged the bump where version sings,
A cherry-pick branch with hopeful spring,
If conflicts rise, an issue I bring,
Two-ten to two-eleven — carrots for the wings! 🥕

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: a new cherry-pick workflow added to the release process for syncing version bumps to main, which is the primary addition in this PR.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

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

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch adjust-verioning

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.github/workflows/publish-release.yml:
- Around line 516-560: Before creating the cherry-pick branch, detect whether
VERSION_COMMIT (or the version bump) is already present on the DEFAULT_BRANCH
and exit cleanly if so; after fetching origin and checking out DEFAULT_BRANCH,
run a reachability check like git merge-base --is-ancestor "$VERSION_COMMIT"
"origin/$DEFAULT_BRANCH" (or git branch --contains "$VERSION_COMMIT"
"origin/$DEFAULT_BRANCH") and if it returns success echo a message and skip
creating CHERRY_BRANCH/PR, otherwise continue with creating "$CHERRY_BRANCH" and
performing the cherry-pick as currently implemented.

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.github/workflows/publish-release.yml:
- Around line 531-567: The cherry-pick failure path treats any non-zero exit
from git cherry-pick "$VERSION_COMMIT" --no-commit as a conflict, but git can
fail because the change is already applied (an "empty" cherry-pick); capture the
cherry-pick output/exit code, detect the empty case (e.g., output contains
"previous cherry-pick is now empty" or "The previous cherry-pick is now empty")
or check for no staged/working changes (git diff --cached --name-only and git
status --porcelain empty), and if empty then run git cherry-pick --abort, echo a
no-op message and exit successfully instead of creating an issue; otherwise keep
the existing git cherry-pick --abort || true and the conflict warning/issue
creation (references: VERSION_COMMIT, git cherry-pick, CHERRY_BRANCH).

[coderabbitai]

🧹 Nitpick comments (2)

.github/workflows/publish-release.yml (2)

466-482: Minor race consideration with concurrent releases from different branches.

If two stable releases from different release branches (e.g., release/2.11.x and release/2.12.x) run concurrently, both may determine they are the "latest" before the other's tag is pushed, potentially creating duplicate cherry-pick PRs.

This is unlikely in practice and the outcome is benign (one PR becomes redundant), but worth noting. The existing per-branch concurrency group at line 31 doesn't prevent this since it's scoped to github.ref.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/publish-release.yml around lines 466 - 482, The race comes
from computing LATEST from local tags; change the logic to compute the highest
stable tag from the remote instead and ensure tags are fetched first: run git
fetch origin --tags, then derive LATEST from the remote tag list (e.g., use git
ls-remote --tags origin and extract tag names, grep '^vX.Y.Z$', sort -V, tail
-1, sed 's/^v//') and then compare that remote LATEST against VERSION to set
is_latest (variables: LATEST, VERSION, is_latest and the current local git tag
pipeline) so concurrent workflows use the authoritative remote tag state rather
than local tags.

---

534-538: Consider using git reset --hard or git cherry-pick --abort for cleaner state.

git reset HEAD only unstages changes but leaves modified files in the working directory. While this won't cause issues in CI (the runner is ephemeral), using --hard or --abort would be more explicit about discarding the incomplete cherry-pick state.

♻️ Suggested fix

             if [ -z "$(git diff --cached --name-only)" ]; then
               echo "Cherry-pick produced no changes — version bump already applied on $DEFAULT_BRANCH"
-              git reset HEAD 2>/dev/null || true
+              git cherry-pick --abort 2>/dev/null || true
               exit 0
             fi

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/publish-release.yml around lines 534 - 538, Replace the
current cleanup step that runs "git reset HEAD 2>/dev/null || true" inside the
block that checks "git diff --cached --name-only" with a more explicit discard
of the incomplete cherry-pick state: first attempt "git cherry-pick --abort"
and, if that fails, fallback to "git reset --hard" (both silenced similarly), so
the script aborts a partial cherry-pick or otherwise hard-resets the working
tree instead of only unstaging changes.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In @.github/workflows/publish-release.yml:
- Around line 466-482: The race comes from computing LATEST from local tags;
change the logic to compute the highest stable tag from the remote instead and
ensure tags are fetched first: run git fetch origin --tags, then derive LATEST
from the remote tag list (e.g., use git ls-remote --tags origin and extract tag
names, grep '^vX.Y.Z$', sort -V, tail -1, sed 's/^v//') and then compare that
remote LATEST against VERSION to set is_latest (variables: LATEST, VERSION,
is_latest and the current local git tag pipeline) so concurrent workflows use
the authoritative remote tag state rather than local tags.
- Around line 534-538: Replace the current cleanup step that runs "git reset
HEAD 2>/dev/null || true" inside the block that checks "git diff --cached
--name-only" with a more explicit discard of the incomplete cherry-pick state:
first attempt "git cherry-pick --abort" and, if that fails, fallback to "git
reset --hard" (both silenced similarly), so the script aborts a partial
cherry-pick or otherwise hard-resets the working tree instead of only unstaging
changes.