All articles

Getting Started

What is CICDoo Getting started: the onboarding wizard The Dashboard and Infrastructure Map

Concepts

Production, staging and development stages Domains, subdomains and SSL Odoo versions and editions (Community vs Enterprise) Workspaces and team collaboration

Servers

Adding a server Server domains and DNS Using a load balancer Server actions: deploy, logs and charts

Projects & Git

Creating a project Connecting GitHub Connecting GitLab Branches and instances

Instances & Console

Creating an instance Restarting, stopping and removing an instance Merging branches between stages Web IDE and remote access Instance settings explained Deployments and the job queue

Agent Tasks

What agent tasks are Setting up agent tasks Running a task and reviewing the result Agent time and top-ups

Monitoring & Backups

Monitoring your instance Backups and restore Alert notifications (email and SMS)

Workspaces & Permissions

Inviting workspace members Member permissions and resource access A member cannot see or use a resource

Account & Security

Two-factor authentication (2FA) Profile and integrations settings Passwords and account recovery

Billing & Plans

Plans and pricing Upgrading and managing your subscription If a project subscription goes unpaid The channel partner program

Support & Tickets

Opening a support ticket Getting help from the CICDoo team

Troubleshooting

Troubleshooting: cannot connect a server Troubleshooting: a deployment failed Troubleshooting: git push fails with 403 after moving a repository Troubleshooting: my instance is down or slow Troubleshooting: domain or SSL problems

Agent Tasks

Running a task and reviewing the result

Creating an agent task, reading and approving the plan, what lands in git, sending work back for another round, and what happens when a run fails or hits a provider limit.

Creating a task

Open a project's Tasks page, or the Tasks tab of an instance console, and create one. You give it:

  • A title and a description. What should change, in plain language. Detail helps: the same ask with two sentences of context produces a much better plan than the ask alone.
  • The instance to work in. This decides which codebase the agent reads and which branch the result is pushed to.
  • Skills and attachments, optionally. Skills are your house conventions; attachments are files the agent should have for context, such as a spec or a screenshot of the problem.

Creating tasks needs the agent-tasks permission. If the project's subscription is unpaid and the project has gone read-only, task creation is refused along with every other action.

Targeting the production instance requires you to type confirm when you create the task, and the task is recorded as a production task from then on.

Reading the plan

The agent picks the task up, reads the codebase and writes back a plan. Nothing has been changed yet at this point.

Read the plan itself, not just its first line. It is your only chance to catch a misunderstanding before code is written, and the cost of reading it is far lower than the cost of unpicking a bad change afterwards.

Then choose:

  • Approve & Execute — the agent implements the plan.
  • Request Changes — describe what is wrong and it plans again, with your feedback in hand.
  • Plan Again — reruns planning as-is, useful when the first attempt failed rather than went wrong. Plan Again With Guidance does the same with a note from you.
  • Cancel Task — stops it.

Approving needs the plan-approval permission.

Sometimes the agent reports the plan as blocked: it has decided it cannot do the work safely or the ask is not clear enough. A blocked plan always waits for a person, even on a project with auto-execute switched on.

What lands in git

Once you approve, the agent makes the change inside the instance's container, commits it, and pushes to that instance's branch. That push redeploys the instance, so the result is running where you can look at it.

There is no pull request. The commit goes straight onto the branch the instance is deployed from, which is why the instance you pick matters and why production is fenced off behind two confirmations.

If the run finishes without needing to change anything, it says so rather than inventing a commit.

When the result is not right

Use Start Another Round on the task. Describe what is wrong and the agent plans a fix, building on the code it already pushed rather than starting over. You approve the new plan before anything runs, and the existing commit stays on the branch.

Rounds are counted on the task, so you can see how many passes a piece of work took and what each one changed.

When something goes wrong

  • The instance will not start with what the run committed. CICDoo moves those commits onto a rescue branch, resets the instance's branch, and brings Odoo back up. Nothing is pushed and nothing is lost: the work is on the rescue branch if you want it.
  • The push fails. The work stays in the container's working tree rather than disappearing.
  • The run hits your provider's usage limit. The task pauses and tells you when the limit resets. Resume carries on with the approved plan from that point; it is the same round, interrupted, not a new one.
  • The run stops reporting. If a container dies mid-work, the task is marked failed rather than left hanging forever. If the agent reports in late after that, the result is still picked up.

Watching usage

The task's Usage tab lists every run behind it: which round and phase, who triggered it, the outcome, tokens in and out, and the time it took. The /agent page rolls this up across projects, with charts over the last 30 days, 90 days or 12 months.

Retries and failures are counted too. That is deliberate: they cost real agent time, and a task that took four attempts should look like it did.

Next steps

For how that time is measured and paid for, see Agent time and top-ups. For enabling the feature and connecting a CLI, see Setting up agent tasks.

If you get stuck, open a support ticket from the Tickets page or the chat widget.

Still stuck? Open a ticket from the app or talk to an engineer.