Releases
A Release collects finished branches, merges them together, and deploys the result to a target system. Releases live under the Releases menu (Developer role and above).
The point of a release is that production receives one coherent change set rather than a stream of individual merges.
Release, item, branch
Three levels are involved, and keeping them apart makes the rest of this page much easier to follow.
| Level | What it is |
|---|---|
| Release | The standing configuration — which repository, which target branch, when to deploy, what to run on the machines |
| Release Item | One concrete deployment. Gets a version number, collects branches, merges them, deploys. A release has many items over time |
| Release Item Branch | One branch's participation in one item, with the exact commit that went in |
You configure the release once. zCICD creates items as needed, and each item collects its own branches.
Configuring a release
| Field | Purpose |
|---|---|
| Name | Human-readable name |
| Project Name | Technical name. No spaces or !?#/\+:, |
| Repo | The repository being released |
| Branch | The target branch that receives the merge — the production line |
| Version Sequence | The Odoo sequence that numbers each item |
| Release Trigger | How items are created — see below |
| Countdown Minutes | Grace period shown before a deploy starts |
| Max Minutes for release | Deadline. An item that overruns fails as too late. Default: 120 |
| Settings for machines | Common settings passed to the target machines. May not contain PROJECT_NAME= |
| Include .git | Whether the .git directory is deployed. Default: off |
| Update I18N | Update translations as part of the release |
| Send Pre-Release Information | Notify before deploying |
| Release Message | Message posted to the ticket system |
Release triggers
| Trigger | Behaviour |
|---|---|
| By Cronjob — merge and prepare | zCICD creates items on a schedule and collects branches automatically. The normal mode |
| Release pushed branch | An item is triggered when the branch is pushed |
| Manual Release | No automatic items. You create them with Hotfix or Build and Deploy |
How an item collects branches
While an item is Collecting, zCICD repeatedly looks for branches to include. A branch is picked up when all of these hold:
- it belongs to the release's repository
- Block Release is not set on it
- its state is Tested, Candidate or Merge Conflict
- it targets this release — or targets no release at all, if this is the only release configured for the repository
- its latest commit has not already been deployed by a completed item
The set is re-synced continuously: new branches are added, a branch whose commit moved gets its commit updated, and a branch that no longer qualifies is dropped again. Any of these marks the item as needing a fresh merge.
If a repository has more than one release configured, a branch must name its target release explicitly via Target Releases. With a single release, branches that name nothing are included by default.
The item lifecycle
| State | Meaning |
|---|---|
| Collecting | Gathering branches; still accepting changes |
| Collecting Merge Conflict | A collected branch will not merge cleanly |
| Collecting Merge Technical Error | The merge failed for a non-conflict reason |
| Integration | Collection closed; merging and testing the combined result |
| Ready to Deploy | Merged and tested, waiting for its deploy window |
| Releasing | Deploying to the target machines |
| Done | Deployed |
| Nothing todo | Nothing had changed; no deploy was needed |
| Failed: Merge Conflict | Could not merge |
| Failed technically | Failed for an infrastructure reason |
| Failed: too late | Exceeded Max Minutes for release |
| Failed: by user | Aborted by hand |
| Failed: merge on master | The final merge into the target branch failed |
Collection stops at stop collecting at, which is derived from the planned date. After that the item moves to Integration and no further branches join.
Once an item reaches Ready to Deploy, zCICD opens a new collecting item behind it, so work continues while the current release waits to go out. This is why you will normally see two open items at once.
Each participating branch carries its own state within the item: Candidate, Merged, Already Merged, or Conflict.
Standard, hotfix and build-and-deploy
| Type | Purpose |
|---|---|
| Standard | The normal scheduled release |
| Hotfix | An out-of-band release for an urgent fix |
| Build and Deploy | Rebuild and deploy without the normal collection cycle |
Hotfix and Build and Deploy are created by hand from the release form. Only one unfinished item of each type can exist at a time — zCICD refuses to create a second until the first is done or failed.
Build-and-deploy items are excluded from the "last item" calculation, so they do not disturb the ordinary release cadence.
Release actions
Release Actions define what actually happens on each target machine. A release can have several, one per machine.
| Field | Purpose |
|---|---|
| Machine | Which machine this action set runs on |
| Docker Registry | Registry to pull or push images from |
| Shell Script Before Update | Runs before the update |
| Shell Script At End (finally) | Runs at the end, whether or not the update succeeded |
| Shell Script at Update Fail | Runs only if the update failed |
| Settings | Machine-specific settings, combined with the release's common settings |
| Update Sourcecode | Deploy the new source. Default: on |
| No 'odoo update' | Deploy without running an Odoo update or stopping the machines |
| Update wodoo images | Refresh the underlying zodoo images |
| Always upgrade odoo | Force the Odoo upgrade step |
| Load images to registry | Whether and how built images are pushed |
| Build No Cache | Build without the Docker cache (set on the item) |
The three shell script hooks are the extension point for anything zCICD does not do natively — stopping a service, warming a cache, notifying a system.
Watching and intervening
- Log on the item records what happened, and Exception Info holds the error if it failed.
- Failed Jobs counts failed queue jobs for the item — a non-zero value is usually the reason an item is stuck.
- Abort stops an item and marks it Failed: by user.
- Changed Lines and Computed Summary give a quick sense of the size of the release, built from the participating branches' end-user summaries.
Troubleshooting
An item sits in Collecting and never progresses. Check that candidate branches are actually in state Tested or Candidate, that Block Release is not set, and — if you have several releases — that they name this release under Target Releases.
Collecting Merge Conflict. One of the collected branches will not merge. Open the item's branch lines to find the one in state Conflict; resolve it in Git, or set Block Release on that branch to take it out of this release.
Failed: too late. The item exceeded Max Minutes for release. This is usually a symptom rather than a cause — look at failed queue jobs first.
Nothing todo. Not an error. Nothing had changed since the last completed item.