Approving a fix
When the agent proposes a code fix, approve it to get a pull request, then merge it with one button when your team is happy.
Sometimes the agent finds a bug and knows how to fix it. It then proposes a fix in the repository, as one of the ticket's fix options. If you approve it, the agent changes the code and we open a pull request for your team to review. The reply to the requester is a separate decision, and never waits for the fix.
Nothing is merged unless an approver asks. An approver merges with the Merge button on the ticket, or by asking the agent to "merge it". Cerberius Agents (the service) does the merge, never the agent, and never because the requester asked.
You can also start the fix from Write › To the agent. Write "go ahead with the fix", and it's as if you clicked Approve. Only owners, admins and approvers can approve or merge a fix. The requester never can.
What you see#
Under Now, Fix options shows the fix as Fix it in the repository it changes, for example Fix it in booking, with what it changes, and what is good (+) and not so good (–) about it. When the agent also proposes a change to your live system, the two sit side by side, A and B, and The agent: says which to choose: one, the other, or both. See Fix options.
The reply the agent wrote is a separate item, Reply to Tom, marked any time: send it whenever you like ("we found it, we're fixing it"). The fix still waits for you either way.
When the agent says what it proposes depends on its questions, they come first: Answer the agent's questions first. Otherwise they come last, and the fix doesn't wait for them.
Click Review and approve to see the risk and the files it expects to change. In What happened, the agent's line has Fix in the repository it proposed, with the description and files.
Approve the fix#
- 1
Read the proposed fix, and the agent's findings in What happened (open Evidence on its line).
- 2
Click Review and approve, then Approve.
Approving the fix sends nothing to the requester, and changes nothing else on the ticket: a reply still waiting stays as it is. Skip instead leaves the fix where it is, saying You skipped it, in case you change your mind.
What happens next#
- The ticket shows Fix in progress, and the option says Being made. What happened says you approved the fix in that repository.
- The agent changes the code in that one repository. It doesn't run the code or its tests.
- We put the changes on a new branch (its name starts with
support-agent/) and open a pull request on GitHub, or a merge request on GitLab. Its description says which ticket it's for and who approved it, and that the agent didn't run or test the change. - What happened says Agent made the fix and opened pull request #4. The link opens the pull request.
- The agent writes a new reply for the requester, telling them a fix is on its way. It takes the place of the reply still waiting, if any: Replaces the agent's earlier reply, not sent.
If the ticket already has an open pull request in that repository, a later fix is added to it. You never get a second pull request for the same ticket and repository.
Merge the fix#
While the pull request is open, the ticket shows Fix ready to merge. Under Fix options, the fix says Pull request #4 is ready to merge, with See it and Merge. The agent's line in What happened says Not merged yet · see Now ↑.
- 1
Click See it to open the pull request on GitHub or GitLab. Review it, and run your usual tests.
- 2
Back on the ticket, click Merge.
- 3
A box opens: Merge pull request #4? It goes live with the next deploy, then the agent looks again. Click Merge.
The option says Merging…, then ✓ Merged. What happened shows that you merged pull request #4. Then the agent looks again: it checks the fix if it can, says whether the other fix option is still needed (a live change that does the same is not), and writes the reply to the requester.
You can also write "merge it" in Write › To the agent. It does the same.
If the merge doesn't work, for example because the key can only read, a note from Cerberius Agents in What happened says The pull request could not be merged, and why.
You can also merge it on GitHub or GitLab yourself. We notice within a few minutes, and What happened says On GitHub someone merged the pull request.
You can send a reply to the requester at any point, before or after the merge.
Review it like any other change
The agent hasn't run or tested its fix. Check the pull request carefully, and run your usual tests before you merge.
Files that are never changed#
A fix can never change these, whatever the agent proposes:
.git,.github,.gitattributes,.gitmodules.circleci,.buildkite.gitlab-ci.yml,Jenkinsfile,azure-pipelines.yml,.travis.yml
These hold your repository's internals and your build and deployment pipelines. A fix that tries to change one is refused.
What you need first#
Approve only works when all of these are true:
| Requirement | Where |
|---|---|
| Code changes are switched on for the platform. Until they are, the agent's fix proposals aren't shown at all. | Settings › Approved changes. See Allowing changes. |
| The repository is one of the platform's repositories, and fixes are allowed for it. | Settings › Code: the Fixes column says Allowed. To change it, open the repository's ⋯ menu, click Edit… and use the Fixes allowed switch. See Repositories. |
| The repository has a key with write access, so we can push a branch, open the pull request and merge it. | Settings › Code and Organisation › Keys. See Keys. |
If something is missing, clicking Approve shows a message saying what, and nothing changes.
If the fix fails#
If the agent can't make the change, or the pull request can't be opened (for example, the key can only read), the fix says It didn't work, with the reason, and Try again. Nothing else on the ticket changes.
After the pull request#
Every few minutes, we check whether the pull request was merged or closed on GitHub or GitLab, for 30 days after it opened. The ticket's status follows. A pull request closed without merging shows Closed without merging on the agent's line, and the fix says It didn't work. Close the ticket when you're done. See Closing tickets.