Checks & promotions
Hold deploys until your repository's GitHub checks pass, and promote the exact commit running on one site to another.
Checks come from your repository
Provisore runs no CI of its own. It reads the check runs and commit statuses GitHub reports on a commit, which covers GitHub Actions and anything else that reports to GitHub. Each site shows them under Continuous integration in its Settings, for the commit at the head of its branch and for its recent deployments.
Checks are read through the Provisore GitHub App, so a site deploying from another git host has none to read. The installation needs Checks: read and Commit statuses: read. When either is missing, the section says which and links to the installation on GitHub, where the owner of the account accepts them.
Require passing checks to deploy
Turn this on and a push no longer deploys straight away. Provisore waits for the pushed commit’s checks and deploys exactly that commit when they pass. A later push replaces one that is still waiting. The push is skipped, with the reason recorded and a deployment.skipped notification, when
- a check fails, is cancelled or times out on GitHub,
- the checks have not finished after 60 minutes, which you can set anywhere from 5 to 360,
- the commit reports no checks at all within 5 minutes, or
- GitHub cannot be read for the whole wait.
Name the checks that matter and the others are ignored, a flaky end-to-end suite for example. A named check that never reports holds the deploy until the wait runs out.
Re-running a failed check brings a skipped push back, as long as it is the site’s newest and less than 24 hours old. It waits again and deploys if the re-run passes.
Provisore hears about check results through GitHub’s check events. An installation that does not send them still works, because every waiting deploy is also read once a minute.
Deploying by hand
Deploy on a site that requires checks deploys the commit at the head of its branch, pinned, so a push landing while it starts cannot change what goes out. When that commit’s checks have not passed, you are shown them and can deploy anyway, wait for them, or cancel. Deploying anyway is recorded against you in the site’s gated deploys and in the audit log. Through the API it is overrideChecks: true.
The deploy hook deploys only a commit whose checks passed and answers 409 otherwise. If the CI job that calls it is itself one of the commit’s checks, name the required checks so that job is not among them. An environment change with redeploy, and a Swift toolchain change, rebuild the commit already live instead of the branch head.
Branch protection decides what may merge. This decides what may deploy, and Provisore does not read your protection rules, so name the same checks here if you want the same set. Checks are read from the commit being deployed. A workflow that runs only on pull requests reports nothing on the merge commit; add push to its triggers for the deploy branch.
Promoting between sites
A site can name another site it promotes to, typically staging to production. Both must deploy the same repository. They can run on different servers and track different branches.
Promote deploys the commit live on the source, not the head of any branch, onto the target. The target builds it with its own environment file, deploy script and settings. Nothing crosses over but the commit, which is fetched by hash, so it does not need to be on the target’s branch. The Pipeline section says when it is not, and warns when the target also deploys on push, because its next push would replace the promoted commit with its branch head.
- Confirmation. Promoting asks you to type the target’s domain.
- Approval. With it on, a promotion waits until an admin or owner other than the person who asked approves it. Nobody approves their own, and an access token cannot approve at all.
- Automatic promotion. Promotes every successful deploy of the source from the moment it is turned on. Rollbacks on the source are not promoted, and neither is a commit the target already runs. It can wait for the commit’s checks first.
- Checks on the target. A target that requires passing checks judges the promoted commit by its own required checks, and asks before promoting past them.
- A busy target. A promotion waits while the target has a deploy in flight and starts when it finishes. A newer promotion replaces one still waiting.
Every promotion is kept in the target’s history with who asked, who approved, the commit, and how its deploy ended, including a later rollback. Deleting the source keeps that history under the source’s name. Deleting the target removes it.