CI, Merge & Branch Actions
Re-run or cancel CI, merge, close, reopen or update a branch from the pull request details. Each action asks you to confirm first.
When one of your pull requests shows Fix CI or Merge ready, the next step is yours. These actions let you take it from the details panel: re-run a failed check, merge, close, reopen, or bring the branch up to date. Nothing runs until you click it, and nothing is retried automatically.
How the actions work
Re-running failed CI jobs takes one click. Every other action opens a short confirmation that reads the pull request's current state from your provider when it opens. If the provider won't allow the action yet, the confirmation tells you why, and when a request fails you see the provider's own error message.
When you merge or update a branch, the confirmation shows the exact commit it will act on. If someone pushes in between, PR Flow stops and asks you to review the new commits first.
Every action that reaches your provider is recorded in Settings → Logs, whether it succeeded or not. A re-run PR Flow holds back itself (see the limits below) is recorded too, marked as not sent. Actions use the provider sign-in PR Flow already has, so your provider's permissions apply unchanged.
Checks: re-run and cancel CI
Open a pull request and the Checks section lists the CI runs on its current commit, with the actions each run allows.
The section opens by itself when a run failed or is still running, and stays folded when everything passed. Click its header to open or fold it. The button on the right of the header follows your CI. When runs failed it offers to re-run them, with the count, in your provider's words — Re-run failed on GitHub, Retry failed on GitLab — and one click re-runs the failed jobs of every one of them. On Gerrit it reads Recheck and asks before posting the comment. On Azure DevOps a re-queue starts a whole new build, so it shows how many failed and you pick them from the list. Otherwise it shows that CI is running or passed. Its arrow opens a list of the runs with their status, where you can tick the runs you want and re-run them together. A full re-run spends CI, so it asks for a second click first. All checks on… in the header opens the full list on your provider. While a run is still going, the list keeps itself up to date, so the button and the section follow it to the end.
| Provider | What you can do |
|---|---|
| GitHub | Re-run failed jobs, Re-run all, or Cancel a running GitHub Actions run |
| GitLab | Retry failed jobs, Run new pipeline for a merge request pipeline, or Cancel |
| Azure DevOps | Re-queue a build validation policy, which starts a new build and cancels one still running |
| Gerrit | Recheck, which posts a comment your CI listens for (see below) |
A few things can't be done from PR Flow:
- Checks from other apps and plain commit statuses can only be re-run on the provider, so they link there.
- GitHub allows re-runs for 30 days after a run, so older runs have no re-run button.
- GitLab pipelines from an external CI, and archived pipelines, can't be retried through GitLab.
- When GitLab accepts a retry but there were no failed jobs to run, PR Flow reports that nothing happened.
The same run can't be re-run twice within ten seconds, and PR Flow stops at five re-runs of one pull request in an hour so you can look at why it keeps failing. Cancelling a run is never limited. When your provider itself is rate-limiting requests, PR Flow says so rather than reporting a permission problem.
From your list: when a required check fails on one of your GitHub or GitLab pull requests, its row in the list and in the menu-bar glance gets a re-run button, so you can retry the failed jobs without opening anything.
Gerrit recheck
Gerrit has no built-in way to re-run CI. Many setups, Zuul for example, re-run when someone comments a keyword such as recheck. To use that from PR Flow, go to Settings → Connections → Gerrit, turn on Re-trigger CI with a comment, and set the exact text your CI expects. The comment is posted under your name, so the confirmation shows the text before it goes out, and PR Flow checks that it lands on the latest patch set.
Where the actions are
On your own pull requests, merge, update, close and reopen share one control in the details panel's footer, between Open on… and Start Review. PR Flow asks your provider what can be done right now and offers only that. A draft shows no merge, a branch that's up to date shows no update, and a merge that branch protection or a required policy would refuse isn't offered either.
- One thing to do: a single button, for example Update branch or Reopen.
- A next step and more: the next step is the main button, and the rest open from the arrow next to it. When the pull request can be merged, Merge is the main button and is highlighted, and Start Review steps back.
- Only close left: a single Close (or Abandon) button. Like every action here, it asks for confirmation first.
Merge
On your own pull requests the footer offers your provider's merge action when it can be done: Merge on GitHub and GitLab, Complete on Azure DevOps, Submit on Gerrit.
How the merge is done follows your repository's settings:
- GitHub: choose among the merge methods the repository enables. In repositories that use a merge queue, the confirmation offers Add to merge queue instead, and the queue decides how and when to merge.
- GitLab: the project's merge method applies. Where the project lets you choose, there is a Squash commits option.
- Azure DevOps: choose among the merge types the target branch's policy allows.
- Gerrit: the project's submit type applies. If submitting this change also submits others, from the same topic or ones it depends on, the confirmation lists them and the button says how many changes will be submitted.
PR Flow remembers your merge method, and whether to delete the branch, per repository. You can delete the source branch as part of the merge on GitHub, GitLab and Azure DevOps. On GitHub the option isn't offered for pull requests from a fork, or when the repository already deletes branches automatically.
When it can't merge yet, no merge is offered. If the branch only needs updating first, Update branch (or Rebase) takes its place. If something changes between opening the confirmation and confirming, the confirmation says why it can't merge, and offers the next step where there is one.
Azure DevOps completes merges in the background. PR Flow waits for the result, and if it takes longer than a minute it tells you the merge is still completing and shows the result on the next refresh.
Close and reopen
On your own pull requests you can close one you've abandoned or bring it back: Close and Reopen on GitHub and GitLab, Abandon and Reactivate on Azure DevOps, Abandon and Restore on Gerrit. Closing deletes nothing, so a pull request can usually be reopened later.
The confirmation has an optional comment, like GitHub's Close with comment. Write why you're closing it, and the button changes to Close with comment. The comment is posted first: on GitHub as a pull request comment, on GitLab as a note, on Azure DevOps as a closed comment thread, and on Gerrit as the abandon message. If the comment can't be posted, nothing is closed. If the provider refuses, for example because the branch no longer exists, its explanation is shown.
Update the branch
When one of your branches has fallen behind its target, the footer offers to update it. It isn't shown while the branch is up to date.
- GitHub, Update branch: merge the base branch in, which keeps your commits as they are, or rebase onto it. A rebase rewrites the branch, so anyone with it checked out has to reset, and the confirmation reminds you.
- GitLab, Rebase: offered when GitLab reports the branch needs one. PR Flow follows the rebase until GitLab finishes and shows GitLab's message if it fails, for example because of conflicts. GitLab then runs whatever pipeline your project starts on new commits.
- Gerrit, Rebase: where your Gerrit offers it, the rebase is done on behalf of the change's uploader, so the uploader stays the same. Otherwise the confirmation tells you that you'll become the uploader of the new patch set.
- Azure DevOps can't update a branch from here, so it is never offered there. Merge or rebase it locally. Open in Editor can check the branch out for you.
What PR Flow leaves to you and your provider
PR Flow merges only when you click, after checking the provider's current state. It doesn't merge when checks turn green later, doesn't join GitLab merge trains, and doesn't get past branch protection or required policies. Those stay with your provider.
Turning actions off
Both groups can be switched off in Settings → Features: CI actions, and Merge, close & update branch. On a Team or Enterprise license, an administrator can lock either one on or off for every seat, for example to allow CI re-runs while keeping merges on the provider.