Your First Branch

This walks through the normal life of a feature branch in zCICD, from creating it in Git to logging in and testing it. It assumes a repository is already connected — if not, see Repositories.

1. Create the branch in Git

Branches are created in Git, not in zCICD. Branch off whatever base your project uses — main, a release branch, or another feature branch — and push it:

git checkout -b feature/my-change main
git push -u origin feature/my-change

Working off a specific base rather than a fixed develop branch is deliberate: it lets you target a particular release or build a hotfix without disturbing the main line.

2. zCICD picks it up

If the repository has Initialize new Branches enabled (the default), zCICD notices the new branch on its next fetch and starts setting it up on its own. You do not have to do anything.

Setting up means:

1. checking out the branch into its own workspace directory
2. generating the Docker configuration for it
3. building the images and starting the containers
4. creating the database — either restored from a dump or created empty with demo data, depending on the repository's New Instance Mode

You can watch this happen: open the branch from Branches and look at the Tasks tab. Each step appears as a task and turns green when it completes.

If you do not want to wait for the automatic fetch, open the repository under Configuration > Repositories and use Fetch all Branches.

Opening a branch shows everything zCICD knows about it:

Under Actions you find the buttons that operate on the instance:

3. Log in to the instance

Once the instance is up, you do not need to know any credentials.

On the branch screen, use Odoo Login. You get a list of users from the test database; pick one and zCICD logs you in as that user.

tip

If login fails, the cached user list is probably stale — for example because the database was reset or restored since the list was built. Press Update Users, wait for the sync task to finish, and try again.

4. Test your change

How you test depends on what you changed, but two actions cover most cases:

• Reset DB (Demo) — wipes the database and rebuilds it with demo data. This is the fastest way to get a clean, predictable system to try a feature on. Requires the Developer role, and asks for confirmation because it destroys the current database.
• Update MANIFEST Modules — updates every module listed in the MANIFEST file. New custom modules get installed, and anything in the uninstall section gets removed. Use this after adding or removing a module.

Automated tests run on their own when new commits arrive; results appear under Test Runs and on the branch's own test run tab.

5. When the instance is not available

This is the most common problem and usually has a simple cause: one or more Docker containers has crashed.

First try Restart. In the Actions area, Restart performs a restart-and-reload — it restarts the instance's containers. This fixes the majority of unavailable instances.

If that does not help, work up the chain:

1. Reload — regenerates the Docker configuration from the current source
2. Build — rebuilds the images, fetches Odoo and Postgres images, installs required packages
3. Update MANIFEST Modules — brings module state back in line

If the instance cannot start at all, open its logs from the branch screen: the error is nearly always there rather than in Odoo's own log.

More detail on every button is in Branch Actions.

6. Getting it reviewed and released

As the branch progresses, its state moves on its own — from Dev through Testable and Tested towards Candidate and Release. Approvers act on it from the branch screen, and once approved it can be collected into a release.

You do not set the state by hand; zCICD computes it from what has happened to the branch.