Release settings sit alongside the rest of a project's settings. Open the project, select Settings, and expand Releases. There are three screens, and each addresses one specific 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 amend release settings. All other users can view them. Link a repository first, as every release references a commit within it.
Environments
Where does a release go, and in what sequence?
Each project begins with Production. Add further deployment stops,
such as Staging or QA, via Add an environment. Give each environment a name. Coroid
suggests a key derived from the name, for instance staging. Your CI/CD uses that key
when logging a deployment, so keep it consistent once pipelines rely on it.
Set the order using Comes after. A Staging environment that follows nothing and Production that follows Staging creates the path Staging › Production. The release page displays the rollout sequence in this order, and approval rules may require prior successful deployment to the earlier environment.
Approval rules
What conditions must be met before a release can deploy to this environment?
Select the environment at the top. Rules apply per environment, so Staging may have lenient requirements while Production has stricter ones.
- Approvals required: the number of distinct individuals who must approve. Zero allows a release to deploy as soon as its checks pass.
- Who can approve: the organisational roles permitted to grant approval.
- Keep requester and approvers separate: the person who initiates the deployment cannot also approve it, and anyone who edits the release notes cannot approve them.
- Quality checks pass: always enabled. The project's Quality Graph with a
release_validationtrigger runs against the exact commit. Publish that graph via the project's quality settings. - Previous environment first: the release must already be deployed to the environment that precedes this one.
- Approved release notes: the current notes require approval, and any subsequent edit needs a fresh approval.
- Checklist: manual steps that someone confirms on the release page, such as "Database migration reviewed". Mark an item as required or optional. A required item can allow a temporary exception. An Owner or Admin logs the reason and sets an expiry of up to 24 hours; the exception applies only to that commit and environment.
- Hotfix rules: less stringent rules for urgent fixes: the required approval count and whether approval for the previous environment and notes still apply. Quality checks and required checklist items always apply, and only Owners and Admins can approve hotfixes.
Select Publish rules to save. Publishing creates a new version of the rules. Approvals granted under the old version become invalid, so a release in progress will request approval again. An environment without published rules cannot pass its checks, and the screen will indicate this.
Deploy pipeline
Who initiates a deployment, and how does Coroid track its progress?
Select the environment at the top, then choose how deployments start:
- My pipeline deploys on its own: keep your existing process. Coroid logs deployments when your CI/CD reports them, or when an Owner or Admin records an external deployment on the release page.
- Coroid triggers a GitHub Actions workflow or Coroid launches a GitLab CI/CD pipeline: displayed when the project's repository is hosted on that provider. Enter the branch or tag that points to the release commit, the workflow file for GitHub, and the exact name of the job responsible for deployment. Coroid verifies the ref before starting the run and checks the named job before confirming success.
Under Deployment reports, generate a reporting token for the environment and store it as a secret within your CI/CD. Coroid displays the token once and retains only a hash of it. Replacing the token instantly revokes the old one. The same screen shows the endpoint, the project ID, and the environment key needed by your pipeline, along with confirmation of whether reports are being received. Deployment events and CI setup provides the event format and examples.
Moving settings between organisations
Settings export and import include environments, their order, pipeline configuration, and published rules, including hotfix rules. Reporting tokens are never exported. Create new ones after an import.