Approval and Code Review
Before a branch can join a release it has to pass through two independent approval gates and, usually, its tests. This page explains what those gates are, who can act on them, and how they combine into the branch state you see in the list.
Approval lives on the commit, not the branch
A branch's approval status is really the status of its latest commit. That is deliberate: the reviewed code, not the branch name, is what gets approved.
By default, pushing a new commit onto an approved branch drops it back to Dev — the reviewed code is no longer the code that would ship. This is the repository setting Auto set Devmode on push, and it is on by default. Switch it off and the previous approval and code review state carry over to the new commit instead.
Each commit carries two separate fields:
| Field | Meaning |
|---|---|
| User Approval | Someone has confirmed the change does what it should |
| Code Review Approval | Someone has reviewed the code itself |
Both use the same three values: Check (waiting), Approved, Declined.
A commit is fully approved only when both are Approved.
Approving
The Approve button advances whichever gate is still open:
- press it while User Approval is Check → User Approval becomes Approved
- press it again once User Approval is decided → Code Review Approval becomes Approved
Decline works the same way in the other direction. Set to check resets both gates back to Check and clears any forced approval.
Whoever presses the button is recorded as the Approver or Code Reviewer.
Who is allowed to approve
The Approver role or above is required — see User Roles.
Beyond that, one rule is enforced by the system:
The approver and the code reviewer must not be the author of the commit. zCICD rejects the attempt with an error.
There are two ways this rule relaxes:
- the repository has Needs Codereview switched off
- the user holds the
cicd.override.approvepermission
The check applies to both gates independently.
The end-user summary requirement
If the repository has Require Enduser Summary enabled (the default), a code review approval is refused unless the branch has an Enduser Summary — either filled in on the branch or pulled from the linked ticket system.
Release branches are exempt.
This is what makes release notes possible: by the time a branch is approved, somebody has written a sentence about what it changes in language a customer can read.
Force approved
Force Approved on the commit bypasses the whole mechanism. Setting it marks the commit approved, and the author restriction and summary requirement are both skipped.
Use it for genuine exceptions only. It is a tracked field, so it stays visible in the commit's history.
There is also No Approvals, which marks a commit as not requiring approval at all. zCICD sets this itself on the merge commit it creates during a release — that commit has no human author to review it. Once a commit is flagged this way, the flag is carried forward to its successors.
How the branch state is derived
The branch state you see in the Branches list is computed from the latest commit's two approval gates plus its test result. You never set it by hand.
| Condition | Resulting state |
|---|---|
| Merged into main | Done |
| No commits yet | Dev |
| User Approval is Check | To Approve |
| User Approval approved, Code Review still Check | Review Code |
| Fully approved, tests not yet finished | Testable |
| Either gate declined | Declined |
| Tests failed and not approved | Dev |
| Block Release set on the branch | Blocked |
| Fully approved and tests passed | derived from the release — Candidate, Release, or Merge Conflict |
Two details worth knowing:
- A branch with no test settings at all counts as "tested" and skips straight past Testable.
- Blocked overrides the release states, so setting Block Release is the way to hold a finished branch back from the next deployment.
Every state change is reported to the linked ticket system, if one is configured.
Typical flow
- Developer pushes to a feature branch. State: Dev.
- Tests run automatically if Test at new commit is set.
- Someone other than the author presses Approve. State: Review Code.
- A reviewer writes or checks the Enduser Summary, then presses Approve again. Both gates are now green.
- Once tests pass, the branch becomes Testable and then Candidate.
- The next release item collects it. See Releases.
Troubleshooting
"Approver mustn't be the same like author." Someone else has to approve, or
the user needs cicd.override.approve.
"Code Review approve needs an enduser summary." Fill in Enduser Summary on the branch, or link a ticket that supplies one.
A branch went back to Dev on its own. Either its tests failed, or a new commit arrived and Auto set Devmode on push reset the approval gates. Both are expected.
A branch is stuck in Testable. Tests are still open or running. Check Test Runs for the branch's most recent run.