Ship a release

A release takes the pull requests of your sessions to production. You select them and press one button. Rondar then does this work on GitHub:

1. Combine pull requests. Rondar puts the selected pull requests on one release branch and opens a release pull request. It corrects merge conflicts.
2. Run checks. It waits for the checks of the repository on the release pull request.
3. Deploy to staging. It merges the release and follows your staging deploy workflow. A repository without a staging workflow has no such step.
4. Merge to production. It opens and merges the pull request into your production branch.
5. Deploy to production. It follows your production deploy workflow until it succeeds.

Rondar does not deploy your app itself. Your GitHub Actions workflows deploy, as they do today. If a platform such as Vercel, Netlify, Render or Railway deploys your app through its GitHub app, Rondar can follow that deploy in place of a workflow. Set up GitHub Actions deploy workflows tells what the repository needs.

A release needs three things:

• A connected GitHub account that can push and merge in the repository.
• One check or more on pull requests, for example a test workflow.
• A production deploy workflow that Rondar can find.

New releases are for web projects.

Open Releases and select New release. With more than one project, choose the project first.

The page lists each session that has an open pull request, with the state of its checks. Select the sessions to ship.

• A session with Checks passing is ready.
• A session with Checks failing, a merge conflict or an old base can be selected too. The release corrects it.
• A session that is at work, a draft pull request, or a pull request that a GitHub rule blocks cannot be selected. The page tells why.

The button at the bottom shows what it will do, for example Release 3 sessions. Press it. This is the one approval that a release needs: from here, Rondar continues without you.

You can close the page. The release continues.

The release page shows a timeline with the steps and the pull requests In this release. A step that failed and was corrected shows how many problems were fixed automatically.

When a check or a deployment fails, Rondar starts a repair session. You can open that session and read what the agent does. Details has the GitHub runs, the logs and the pull requests that Rondar opened.

One release runs at a time for each repository. A second release waits and starts after the first one.

A release has limits. It stops when a repair does not succeed after three tries, or when a step is too long. The page then shows Rondar stopped this release.

• See what failed shows the cause.
• Start a new release with these pull requests starts again after you correct the cause.

When a release stops, Rondar closes the pull requests and deletes the branches that it made for the release. The page lists what it removed, and anything that you must remove by hand. Your own pull requests stay open and are not changed.

Select Abort release while a release is at work. Rondar stops, and removes the pull requests and branches that it made. Your own pull requests stay open.

On the newest shipped release, open Details. Revert the merge opens a pull request that removes the changes of the release from the base branch. Review it and merge it on GitHub.

In the project settings, under Releases, the option Auto-archive sessions after their release is completed archives the sessions of the shipped pull requests.