Request changes

You do not have to wait for the pull request to change course, and you do not have to leave Taiga to review it. Tell Taiga what should change, and it works your request into the same run and the same pull request, and answers each thing you asked for.

Send a request

On the initiative page, choose Request changes.

• For an initiative’s own run, the button is there until the run is finished: while it builds, while it is paused, and while its pull request waits for your review.
• For a fix Taiga raised itself, such as a dependency update, the button is there while the pull request waits for your review.

Either way, that includes a pull request Taiga handed back to you, for example one it kept a draft because the tests it ran failed, or one whose CI it could not fix.

Write what should change the way you would write it to a colleague: a list of changes, a question, or both. You can paste or drop screenshots where they belong in the text, as in an initiative description. Then choose Send to Taiga.

What Taiga does with the request depends on the run. An initiative’s own run is re-planned, and a fix Taiga raised is reviewed.

An initiative’s own run

Taiga re-plans the work that is left on top of what the run has already built, and the run carries on with the new plan. It stays the same initiative and the same run, and the work goes to the same pull request.

You can ask for new work, ask to change or drop steps that have not been built yet, or ask to undo something that has been built. If you want to see the new plan before the run goes on, tick Show me the new plan before the run continues.

When the re-plan starts

Taiga does not stop in the middle of a step. The run stops after the step it is building, so what is committed is always a finished step. If the run is not building a step when you ask, for example because its pull request waits for your review, the re-plan starts at once.

If you ask while the run is hardening or checking CI, your request waits until the run is at rest. Until the re-plan starts, the initiative page says your request is queued and what it waits for: the step the run is on, by name, or its security pass or checks. You can send more requests while one is queued. They join it and are planned together, up to ten in one re-plan; any more are taken up in the next. Taiga does not merge a pull request while a request is waiting.

While a re-plan is in progress, the initiative page says so and quotes your request, and Request changes is unavailable until the new plan is ready.

What the planner does

The planner revises the steps that are left, on top of the code the run has already built. It can:

• add steps;
• change or drop steps that have not been built yet;
• undo built steps. Undoing a step reverts its commit exactly, with no new code in that step.

It also revises the initiative’s acceptance criteria to match. It looks at up to four screenshots across the requests in one re-plan, the earliest requests first.

The run then continues with the revised steps. It hardens and checks CI as usual, and the pull request’s description has a Changes requested during this run section that says who asked, what they asked, and what changed.

The answer

When the run finishes building and updates its pull request, Taiga replies on the pull request once for each request. The reply quotes the request and lists the steps added or changed for it and whether each was built, or says why the request was not planned.

While the run builds the revised plan, the initiative page says Plan revised for your request, with how many steps were added, changed and dropped. In the plan, a Revised for line marks where the new plan starts, the steps the re-plan added or changed are marked Added or Changed, and the steps it dropped are folded under the list. Steps an earlier request added or changed are marked From a request, and the plan is marked Revised. The initiative’s activity shows your request, the steps that were added, changed, dropped or undone, and the answer to your request.

Review the new plan first

If you ticked Show me the new plan before the run continues, the run waits for you. The initiative reads Review the revised plan, and the plan appears under Action Required:

• Approve continues the run with the revised plan.
• Request changes sends the plan back with your comment. The planner revises the plan again, keeping what you did not object to, and you review it again.

When Taiga will not plan a request

Sometimes Taiga cannot plan a request:

• It conflicts with a policy. For example, it asks to store something your organization’s security policy forbids. The planner does not plan around the policy.
• The re-plan fails.

Either way, the run stops on its original plan, and the initiative says why. To carry on as planned, resume the run. To try something else, send another request.

A fix Taiga raised

For a fix Taiga raised itself, Taiga works the request the way it works a review: it splits your request into its separate asks, works them on the pull request, and pushes the commits to it. A question is answered, not turned into a change. An ask that is unclear, or would need a product or architecture decision, is left undone with the reason, rather than guessed at.

When it is done, the pull request has one reply that quotes your request and says, for each ask, whether it was done, answered, or not done and why. A done ask names the commit, and the files changed by the step that worked it (one step can work several asks). An ask that takes away something the initiative asked for is still done, because it is your call, and the reply says what it takes away. The initiative’s activity shows your request and the answer, and the initiative is back with you for review.

While Taiga works on it, the initiative reads Addressing PR feedback. When the initiative is back with you, you can review again, merge, or send another request.

Good to know

• A request is limited to 10,000 characters.
• In a fix’s request, Taiga looks at up to four screenshots.
• You can still review or comment on GitHub, on any run: Taiga takes your feedback up and pushes its fixes to the same pull request, as Review Taiga’s pull requests describes.
• Once a pull request is merged or closed, there is nothing left to change.