Orbit Releases

The Releases tab turns your git tags into a version history you can read: every tagged deployment, in order, with its commit, its author, its status and a link straight to the tag in your repository.

Where Releases Lives

Open Orbit, click the project, and choose Releases under the Deployments group in the project tab strip. The page is titled Releases and describes itself as tag-based deployments: a release is created when a git tag matches your tag pattern.

The neighbouring Deployments tab lists every build, tagged or not. Releases is the filtered view: only the ones you marked as a version.

Setting the Tag Pattern

Releases start with a pattern. Open Settings, find the Git tag deploys card, and enter a glob such as v* or release-*. Leaving it empty disables tag deploys entirely, which is why the field's placeholder reads v* (disabled).

With a pattern set, pushing a matching tag deploys to production and records the result as a release. Without one, the Releases tab shows an empty state prompting you to push a tag and set a pattern in Settings.

A tag pattern gives you a second, explicit path to production alongside pushes to the production branch. Teams that want deploys to be a deliberate act rather than a side effect of merging often turn branch auto-deploy off and drive production from tags only.

Cutting a Release

The whole flow from your side is two git commands:

git tag -a v1.4.0 -m "Checkout flow rebuild"
git push origin v1.4.0

Orbit receives the tag, matches it against your pattern, deploys the tagged commit to production, and records a release. It appears on this tab with a Building badge and moves to Deployed when it lands, or Failed if the build errored.

Use annotated tags rather than lightweight ones. An annotated tag carries a message, an author and a date, all of which end up on the release.

Tagging an Existing Deployment

You do not have to push a git tag to get a release. Any deployment can be tagged from its detail page, and a tag that looks like a version number is picked up here.

A version-shaped tag is one like 1.4, 1.4.0, v1.4.0 or v2.0.0-rc1. Anything else stays as a plain deployment tag and does not create a release entry.

This is the escape hatch for the case where a release went out before you set up the pattern, or where a hotfix was deployed by hand and you want it in the version history anyway.

Reading a Release

Each release row shows:

The tag, as the release's title.
The commit and its message.
The author, shown as by name.
The environment it went to, colour coded by type.
A status badge: Deployed, Building or Failed.
A View on link to the tag in your repository.
A link through to the underlying deployment.

The View on link points at the right place per provider: the releases page on GitHub, the tag page on GitLab, or the source at that tag on Bitbucket.

Release Notes

If you publish a release in your repository for a tag, the notes are pulled across and attached to the deployment, so the Releases tab carries the same text you wrote in your repository rather than making you keep two copies.

That makes the repository the single place to write release notes. Write them once, where your contributors already are, and they show up here.

One Release Per Tag

The list is deduplicated by tag: if a tag has been deployed more than once, for example because the first build failed and you retried, only the most recent deployment for that tag is shown.

The counter at the top gives the total, and the list covers a generous window of recent tagged deployments rather than the entire history of the project.

Using Releases Well

Tag on merge, not on the branch. Tag the commit that is actually on your production branch. Tagging a feature branch commit that has not been merged produces a release that does not correspond to anything on main.

Use semantic versions. They sort correctly, they are recognised as version-shaped, and everyone already knows how to read them.

Never move a tag. Re-pointing an existing tag at a new commit means the release in this list and the tag in your repository now disagree about what shipped. Cut a new patch version instead.

A tag push deploys straight to production if it matches your pattern. That bypasses nothing else: deploy locks, approval requirements and freeze windows still apply as configured. But it does mean a tag pushed by mistake is a production deploy, not a draft. See Deploying Your Project for the gates available.

Rolling Back a Release

Releases are deployments, so rolling one back is the ordinary rollback flow: open the deployment and restore the previous successful one. See Rolling Back a Deployment.

Afterwards, cut a new tag for the fix rather than deleting the bad one. The failed release staying visible in the history is useful information, not clutter.

Troubleshooting

A tag was pushed but no release appeared. Check the pattern in Settings, then check that the tag actually reached the remote. git push origin v1.4.0 pushes one tag; git push alone pushes none.

The release shows Failed. The build failed, exactly as it would for a branch push. Open the deployment and read the log: Reading Build Logs.

The View on link is missing. The project has no connected repository, so there is nowhere to link to. Connect one: see Connecting a GitHub Repository.

A manually tagged deployment is not listed. The tag is not version-shaped. Rename it to something like v1.4.0.

Release notes are empty. Notes are pulled from a published release in your repository. A bare tag with no release object has no notes to pull.

Where To Go Next

Deploying Your Project for the full deploy cycle and its gates.
Rolling Back a Deployment when a release goes wrong.
Orbit Timeline Annotations to record what a release changed.