Choose where Taiga waits for a decision

Separate four decisions

The fictional equipment service has four different decisions: accept the plan, execute the build, merge the change, and deploy it. Do not treat one switch as authorization for all four.

Before changing autonomy, inspect what the repository pipeline does after merge. If merging to the working branch triggers deployment, an automated merge can trigger that existing workflow too.

Decide whether a plan waits

The product setting Build on its own by default controls whether a completed plan proceeds to a build or waits for approval. Turn it off when plans need a human decision first.

An initiative’s Build on its own setting can change that behavior for the individual initiative. Inspect both the default and any specific choice before queuing work.

Approve starts the build as the approving person, subject to their current permissions. A failed plan starts no build. Build automation does not by itself authorize merging the resulting pull request.

Understand the merge hierarchy

Autonomous merge is separately controlled and is off until enabled. The documented integration supports GitHub, including GitHub Enterprise.

A disabled organization or factory ceiling cannot be overridden below it. A product default of off is different: an initiative can enable its own merge if the ceilings allow it.

For the equipment service, keep the initial scope explicit. One low-consequence initiative can have a different choice from a change to employee access controls, within the permitted boundaries.

Make required reviews enforceable

Taiga asks the source-control provider whether the pull request may merge. Your branch protection determines the required checks, reviews, and other conditions. Autonomous merge does not bypass those rules.

If an automated review must block merging, make its result a required status check through the repository’s supported configuration. An advisory result does not become mandatory because you expect it to be.

Check required human approvals as well. A green check is not a substitute for an approval that your policy requires. Confirm the rules on the actual target branch.

Interpret a stopped merge

Read the reason on the initiative. A pending check, missing approval, conflict, and incomplete plan require different responses. Taiga also stops autonomous merge when fixes change the criteria that made failed checks pass. Review that change directly.

Do not remove a required check simply because it blocks progress. If the check never reports, correct its configuration or use the authorized policy process. Inspect the current commit after any fix.

Keep deployment authorization separate

The Taiga GitHub App performs an autonomous merge and is recorded as the merger. The repository pipeline retains its existing deployment behavior.

For this scenario, merging deploys to staging. Production still requires the organization’s production decision and evidence. Confirm that the pipeline enforces this separation. Continue with delivery review.