Autonomous merge

By default an agent run stops at a pull request and waits for you. Autonomous merge changes the last step: once your own rules allow the merge, Taiga presses the button instead of waiting.

Nothing else about the run changes. The agent still plans, builds, pushes and opens a pull request the same way, and the pull request is still an ordinary one in your repository.

Taiga merges through your rules, never around them

This is the part worth understanding before you turn it on.

Taiga asks your source-control provider whether the pull request may merge, and respects the answer. The merge is an ordinary API call that your branch protection evaluates exactly as it would for any other contributor. If your rules require an approving review, a passing check, an up-to-date branch or a resolved conversation, the merge waits for it.

Taiga never asks to be a bypass actor on your repository, and never requests an exception to a rule you set. A refusal from your rules is an answer Taiga records and reports, not an obstacle it works around.

The merge itself uses a method your repository allows. Taiga prefers a merge commit, then a rebase, then a squash, in that order, because each step down that list keeps less of the work’s history in your repository. If your repository only allows squash merging, Taiga squashes; you never need to configure this. When it squashes, the merge commit’s description is the pull request’s description, so what lands in your history is the summary you reviewed rather than a list of the agent’s working commits.

The practical consequence: auto-merge can only ever merge something you would have been allowed to merge yourself. It cannot widen what your repository permits. It only removes the wait.

Who does the merging

The merge is made by the Taiga GitHub App you installed on the repository, using that installation’s own credentials. Your repository’s history and your audit trail show the app as the merger, not a person, and not the person whose work it was. Whoever started the run is recorded as the work’s author, in Taiga’s own audit log and on the run, but they are never made to appear as if they pressed merge.

Autonomous merge works on GitHub today, including GitHub Enterprise. A product whose repository lives on another provider keeps the ordinary behavior: the run opens its pull request and waits for you, and the initiative says that Taiga cannot merge there yet.

Turning it on

Autonomous merge is off until you switch it on, and the switch that opens it is at the organization level.

Go to Organization settings, find Autonomy, and turn on Allow merging on its own. Turning it off stops Taiga merging anything, immediately, everywhere in the organization. Pull requests already open stay open and become yours to merge as before.

Factories, products and initiatives

Below the organization there are two ceilings and one default, and the difference matters.

Your organization and your factories are ceilings. Turning autonomous merge off at either stops it for everything underneath, and nothing below can turn it back on. A factory that turns it off stops autonomous merges for every product and initiative under it.

A product sets a default, not a rule. Its switch decides what initiatives in that product do when nobody has decided for them. An individual initiative can still be switched on even where its product defaults to off, which is how you let one piece of work merge itself without reopening the whole product.

An initiative’s own switch is the final word, within what your organization and factories allow. It lives on the initiative page under Autonomy, as Merge on its own. Leaving it untouched means it follows the product’s default; touching it makes a decision that later changes to that default no longer override.

If you cannot turn autonomous merge on somewhere, your organization or a factory has turned it off above, and that is where to change it. Most organizations only ever touch the top one.

Making Taiga wait for your code reviewer

If you run your own automated reviewer, whether that is GitHub Copilot, CodeRabbit, Greptile or anything else, you decide whether Taiga waits for it.

Add that reviewer as a required status check on the branch. Your provider then blocks the merge until the reviewer reports, and Taiga waits with it, because Taiga is reading your provider’s answer rather than forming its own.

Anything you have not made required is treated as advisory. Taiga does not try to detect which tools you have installed or guess which of their opinions you meant to be binding. That is deliberate: a tool that guessed would eventually guess wrong, and the setting that decides it is one you already control.

The same applies to human review. If your branch protection requires an approval, auto-merge waits for a person to give it, then merges once the rest of your rules are satisfied.

When nothing reports on a pull request

Some pull requests get no checks at all. Your repository may have no workflows, or none of its workflows may have started for this change, and either way nothing ever reports on the commit.

Taiga does not wait on them forever. Once it is clear that nothing is going to report, it treats the pull request as having no checks to wait for, and auto-merge considers it from there. The exception is a commit that asks for checks to be skipped: that pull request keeps waiting, because skipped checks are not the same as a repository with none.

This does not lower the bar your repository sets. Taiga still asks your provider whether the merge may happen, so if your branch protection requires a check that nothing in the repository produces, your provider refuses and the initiative names the check that has never reported. What ends is the waiting, not the rule.

Seeing why a merge has not happened

When auto-merge is on but a pull request has not merged, the initiative says why.

The reason appears on the initiative, under the pull request state, and names the specific thing that is blocking it: a review that is still owed, a check that is still running or failing, a branch that conflicts with its base, or a rule in your repository that refused.

Two kinds of reason are worth telling apart, and the panel does:

• Waiting means the block clears on its own. A check finishing, a review arriving. Taiga merges as soon as it does.
• Stopped means it does not. A closed pull request will not reopen, and a rule in your repository will not change its mind.

A conflict with the base branch is reported as stopped, but it is not the end: the agent resolves the conflict and pushes the result, and once the checks pass on the new commit Taiga tries the merge again. It stays stopped only when the agent could not resolve the conflict, which it says on the pull request.

Waiting is not forever, but it restarts whenever a review arrives. If a block that should clear on its own has not cleared after about an hour of quiet, Taiga stops trying and says so, and the pull request stays yours to merge by hand.

That hour counts quiet, not total time. Every review submitted on the pull request gives Taiga a fresh hour, however long the pull request has been open, so a review left until the next morning or the next week still merges when it arrives.

The usual cause of a real stop is a required check that never reports, which nothing but a person can fix — and when that happens, Taiga names the check. If your rules require something nothing in the repository produces, say a code scanning tool that was never set up, the panel says which check or tool has never reported, so the fix is a settings change rather than an investigation. The name stays on the initiative after Taiga stops trying, because that is when you are most likely to be reading it.

One stop is about the run rather than the pull request. A run that did not finish every step of its plan is never merged on its own, however green its checks. It does not reach the review gate at all: the initiative reads Build interrupted (or Build failed, when the step failed on its own code rather than on time or context) and offers Retry from failed step, the run page says which step stopped it, and the partial pull request stays open as a draft for you to read. Whether that partial work is worth merging by hand is your call.

One stop is about checks that start and never finish. If they still have no answer after about a day, Taiga stops waiting and hands the pull request back to you; a review submitted on it starts the wait over.

One more is about how the checks turned green. When a check fails on the agent’s pull request, Taiga pushes commits to get it passing. If those commits also changed something that decides whether checks pass, such as a workflow file or a test configuration, then a green reached that way is not evidence the code works, and Taiga does not merge on it. It stops at once rather than waiting out the hour, names the file it stopped on, both on the initiative and in a comment on the pull request, and leaves the merge to you. Asking the agent to look again does not clear this one, on purpose: looking again is not the same as you accepting the change to the checks. If the change is sound, merge by hand.

If you see none of these, nothing is blocking the merge and nothing needs your attention.

What this does not change

Merging is not shipping. Auto-merge merges a pull request into your branch and stops there. Whatever your pipeline does after a merge, it does exactly as it did before, on the same triggers. If merging to your main branch deploys, then auto-merge inherits that, which is worth knowing before you switch it on for a repository that deploys on merge.