Failing tests and the task decision

Sometimes a project has tests that were failing before your task — they were broken earlier and have nothing to do with your request. So that the agents do not waste time on someone else’s breakage, such tests are handled before development begins.

How it works

Before the agents take on the task, the project’s tests are run on the task branch. If something fails, it is a pre-existing failure (the task has not changed anything yet). Each such failure is checked separately, and tests that are really broken are temporarily taken out of the run on the task branch — with the reason and the confirmation of the failure kept. Nothing is faked into “green”: only genuine pre-existing failures are taken out, and only when the test itself is at fault, not the environment.

After that the task pauses and waits for your decision — you see the list of what was found.

Your decision (one for the whole set)

• Ignore for this task — a temporary block: the tests are taken out of the run for this task only. The agents work from a “green” start, and when the task is merged into the main branch these temporary exclusions are lifted — they do not affect the project.
• Ignore permanently — the tests are treated as disabled at the project level and stay excluded after the task too (this goes into the main branch). Suitable when a test is broken for a long time and this is a deliberate decision.
• Hold the task until fixed — make no decision now; the task waits until you come back (for example, once the tests have been fixed).

Disabled tests and their reasons are always visible in the “Test settings” section.

This only concerns tests that were failing before the task. Breakage introduced by the development itself is caught by the check at the review stage — the decision there is made differently.