allow v2.0.0 to publish prerelease cuts

[akshaydeo]

Summary

Adds the v2.0.0 branch as a trigger for the release pipeline so that releases can be cut directly from that branch in addition to main.

Changes

• Added v2.0.0 to the list of branches that trigger the release pipeline on push, enabling the pipeline to run when changes are pushed to the v2.0.0 branch.

Type of change

• Bug fix
• Feature
• Refactor
• Documentation
• Chore/CI

Affected areas

• Core (Go)
• Transports (HTTP)
• Providers/Integrations
• Plugins
• UI (React)
• Docs

How to test

Push a commit to the v2.0.0 branch and verify the release pipeline is triggered automatically.

Screenshots/Recordings

N/A

Breaking changes

• Yes
• No

Related issues

N/A

Security considerations

No security implications. This only affects which branches trigger the CI release pipeline.

Checklist

• I read docs/contributing/README.md and followed the guidelines
• I added/updated tests where appropriate
• I updated documentation where needed
• I verified builds succeed (Go and UI)
• I verified the CI pipeline passes locally if applicable

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[akshaydeo]

• allow v2.0.0 to publish prerelease cuts #4978 👈 (View in Graphite)
• dev

This stack of pull requests is managed by Graphite. Learn more about stacking.

[akshaydeo]

Merge activity

• Jul 6, 11:02 PM UTC: A user started a stack merge that includes this pull request via Graphite.
• Jul 6, 11:02 PM UTC: @akshaydeo merged this pull request with Graphite.

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 8 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 1e7ebfa7-2bbc-4c9b-8389-3e8a1fba3b3b

📥 Commits

Reviewing files that changed from the base of the PR and between c17bf16 and 35945b1.

📒 Files selected for processing (1)

• .github/workflows/release-pipeline.yml

📝 Walkthrough

Walkthrough

The GitHub Actions release pipeline workflow's push trigger branch filter is updated to include the v2.0.0 branch alongside main, expanding when the release pipeline runs automatically.

Changes

Release Pipeline Trigger Update

Layer / File(s)	Summary
Add v2.0.0 branch to push trigger .github/workflows/release-pipeline.yml	The on.push.branches list is changed from ["main"] to ["main", "v2.0.0"].

Estimated code review effort: 1 (Trivial) | ~2 minutes

Related Issues

• #123: Not addressed by this change; this PR only updates a CI workflow trigger and does not add Files API support.

Suggested labels: ci, chore

Suggested reviewers: N/A

🐰 A branch is added, quick as a hop,
Now v2.0.0 joins main at the top,
The pipeline stirs with a gentle click,
One line changed, and the build runs slick.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch 07-06-allow_v2.0.0_to_publish_prerelease_cuts

---

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

[greptile-apps]

Confidence Score: 4/5

Safe to merge — the one-line branch addition is well-supported by prerelease guards already in every downstream script.

The existing scripts (detect-all-changes, create-docker-manifest, release-core, release-bifrost-http-finalize) all key off the presence of a hyphen in the version string to avoid promoting prerelease artifacts to latest. The change is additive with no logic alterations. Two minor quality issues: the header comment becomes stale, and the shared concurrency group now serialises releases across both branches.

release-bifrost-http-finalize.sh (not in this diff) contains release notes text that unconditionally mentions the latest Docker tag even for prerelease builds.

Important Files Changed

Filename	Overview
.github/workflows/release-pipeline.yml	Adds v2.0.0 to the push branch trigger; core prerelease safety logic is already in the downstream scripts. Stale header comment and shared concurrency group are minor concerns.

Comments Outside Diff (2)

1. .github/workflows/release-pipeline.yml, line 15-18 (link)

   Shared concurrency group will serialise cross-branch releases

   The concurrency.group is set to the literal string "release-pipeline" with no branch qualifier. Now that two branches trigger this workflow, a prerelease run on v2.0.0 and a stable release run on main will compete for the same concurrency slot. With cancel-in-progress: false neither is cancelled — the second simply queues — but a long v2.0.0 CI run (tests + builds) will hold up any main release that arrives while it is running. Consider scoping the group to the branch: release-pipeline-${{ github.ref_name }}.

2. .github/workflows/release-pipeline.yml, line 1-6 (link)

   Release notes body mentions latest Docker tag unconditionally

   release-bifrost-http-finalize.sh (line 153) always includes the line **`maximhq/bifrost:latest`** - Latest version (updated with this release) in the GitHub release notes body, even for prerelease builds where create-docker-manifest.sh intentionally skips pushing the latest tag. Users reading the prerelease GitHub release notes will be told the latest tag was updated when it was not. The fix belongs in release-bifrost-http-finalize.sh: gate that bullet on [[ "$VERSION" != *-* ]].

_{Reviews (1): Last reviewed commit: "allow v2.0.0 to publish prerelease cuts" | Re-trigger Greptile}

[greptile-apps]

The top-of-file comment is now inaccurate — it still only mentions main but the trigger has been broadened to include v2.0.0.

Suggested change

	# Triggers automatically on push to main when any version file changes
	# Triggers automatically on push to main or v2.0.0 when any version file changes

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!