Release settings live with the rest of a project's settings. Open the project, choose Settings, and expand Releases. There are three screens, and each answers one question.
- Environments
- Where does a release go? Add stops and put them in order.
- Approval rules
- What must be true first? Approvals, roles, checklist, and hotfix rules per environment.
- Deploy pipeline
- Who deploys, and how does Coroid hear back? Your pipeline or Coroid starts it; a reporting token lets CI/CD confirm the result.
Only Owners and Admins can change release settings. Everyone else can read them. Connect a repository first, because every release points at a commit in it.
Environments
Where does a release go, and in what order?
Each project starts with Production. Add the other stops you deploy to, such
as Staging or QA, with Add an environment. Give each one a name. Coroid
suggests a key from the name, for example staging. Your CI/CD uses that key
when it reports a deployment, so keep it stable once pipelines use it.
Set the order with Comes after. Staging that comes after nothing and Production that comes after Staging gives the path Staging › Production. The release page shows its rollout track in this order, and approval rules can require the earlier stop to succeed first.
Approval rules
What must be true before a release deploys here?
Choose the environment at the top. The rules are per environment, so Staging can be light and Production strict.
- Approvals required: how many different people must approve. Zero lets a release deploy as soon as its checks pass.
- Who can approve: the organization roles allowed to approve.
- Keep requester and approvers separate: the person who starts the deployment cannot also approve it, and whoever edits the release notes cannot approve them.
- Quality checks pass: always on. The project's Quality Graph with a
release_validationtrigger runs against the exact commit. Publish that graph from the project's quality settings. - Previous environment first: the release must already be deployed to the environment this one comes after.
- Approved release notes: the current notes need approval, and any later edit needs a new one.
- Checklist: manual steps someone confirms on the release page, such as "Database migration reviewed". Mark an item required or optional. A required item can allow a temporary exception. An Owner or Admin records a reason and an expiry of up to 24 hours, and the exception covers only that commit and environment.
- Hotfix rules: lighter rules for urgent fixes: the approval count and whether the previous environment and note approval still apply. Quality checks and required checklist items always apply, and only Owners and Admins approve hotfixes.
Choose Publish rules to save. Publishing creates a new version of the rules. Approvals given under the old version become out of date, so a release in flight asks for approval again. An environment with no published rules cannot pass its checks, and the screen says so.
Deploy pipeline
Who starts a deployment, and how does Coroid learn what happened?
Choose the environment at the top, then pick how deployments start:
- My pipeline deploys on its own: keep your current process. Coroid records deployments when your CI/CD reports them, or when an Owner or Admin records an external deployment on the release page.
- Coroid starts a GitHub Actions workflow or Coroid starts a GitLab CI/CD pipeline: shown when the project's repository is on that provider. Enter the branch or tag that points at the release commit, the workflow file for GitHub, and the exact name of the job that deploys. Coroid checks the ref before it starts the run and checks the named job before it accepts success.
Under Deployment reports, create a reporting token for the environment and store it as a secret in your CI/CD. Coroid shows the token once and keeps only a hash of it. Replacing the token stops the old one immediately. The same screen shows the endpoint, the project ID, and the environment key your pipeline needs, plus whether reports are arriving. Deployment events and CI setup has the event format and examples.
Moving settings between organizations
Settings export and import carry environments, their order, pipeline configuration, and published rules, including hotfix rules. Reporting tokens are never exported. Create new ones after an import.