Cogny Sites Can Now Revert a Deploy That Fails Its Check

Since yesterday every production deploy on Cogny Sites is checked before your visitors get it. A version that fails never goes live.

That left one problem. The commit that failed is still on your production branch. The next person who merges gets a deploy that contains it, and that deploy fails the same check, for a reason that has nothing to do with their change. Nobody can ship until someone reverts or fixes the first commit.

Cogny can now do that revert for you.

What happens when a check fails

With Revert a deploy that fails the check turned on:

1. Visitors stay on the version that works, as before.
2. Cogny adds one commit to your production branch that makes its files identical to that version. Nothing is deleted and nothing is force-pushed: the failed commit stays in the history, followed by the revert.
3. Every pull request that was merged since the live version gets a draft pull request that puts it back. It quotes what the check reported, for example /pricing: expected 200, got 500, and the original pull request gets a comment that links to it.
4. The next merge deploys normally.

The revert commit says which changes it took off and why, so git log tells the story without opening Cogny.

When a deploy contained several changes

Merges that land while a deploy is building are deployed together. If that deploy fails, the check can't tell which change broke it, so all of them come off and each gets its own draft pull request. Fix the one that caused it. The others can be marked ready and merged again as they are.

What it won't do

• It doesn't act while something newer is on its way. If another commit was pushed while the failed deploy was building, that commit contains the failed one and may be the fix. Its own deploy decides.
• It doesn't rewrite history. The revert is an ordinary commit on top of the branch.
• It doesn't push past branch protection. If your branch refuses the push, the same revert is opened as a pull request for you to merge.
• It doesn't undo database changes. Your visitors were on the previous code the whole time; the revert makes the branch match it.
• It doesn't revert more than 20 commits, or a branch whose history was rewritten since the live version. Those are left for a person.
• A pull request that was merged with a merge commit, not squashed or rebased, gets no draft pull request. Put it back by reverting Cogny's revert commit.
• Commits pushed straight to the branch are named in the revert commit and get no pull request.

Turning it on

It is off by default, because it pushes to your repository. An owner or admin turns it on under Sites → your site → Deploy check, or asks their agent to call set_site_deploy_check with revert_on_failure: true. It needs the deploy check itself to be on, and a GitHub connection that may push to the repository.

Afterwards, the failed deployment in Sites shows what Cogny did with the branch, and get_site over MCP shows the same line. The Cogny Sites guide for agents has the details an agent needs.

Why this matters if agents write your code

A check before the merge makes every change wait for a full build and a test run, including the many that were fine. A check before visitors, with the revert done for you, lets changes merge as soon as they build: the broken ones are caught at the last step, taken off the branch, and handed back to whoever wrote them, person or agent, with what failed.