Gates: deploy and merge

Embed
Preview of the card
<a href="https://watchtowerops.net/docs/gates"><img src="https://watchtowerops.net/docs/_api/public/orgs/aa5959cb-1a0b-4a9a-bc9a-913e7ac31cd9/spaces/b7aac181-9916-4805-b253-becc5fd2ca62/pages/05c24683-38ce-49eb-9b0b-7382f75a6dc1/social-card.svg?v=3e7ae33eec8b" alt="Gates: deploy and merge" width="600" height="315"></a>

Watchtower has two kinds of gate. They answer different questions and run at different times, so they are separate resources. Pick by when the decision is made.

Deploy gate

Merge gate

Path

/v1/projects/{prj}/gates/deploy (also /quality-gates)

/v1/projects/{prj}/gates/merge (also /ci/gates)

Runs

After a release is deployed, on its own, once the window_min has passed

Before merge, when your pipeline calls POST .../{id}/evaluate?sha=&branch=

Reads

The service's error rate and p95 after the release

The commit's failed tests, new flaky tests and coverage

Decision

Watchtower records pass or fail on the release (GET /releases/{version}/gates)

Yours: the response lists the breaches, your pipeline sets the exit code

Body

name, env_id, service, conditions, window_min

name, rules (new_flaky_tests, failed_tests, coverage_min), branches

Use a deploy gate to catch a release that is healthy in CI and sick in production. Use a merge gate to keep a commit out of the main branch. A team that wants both creates one of each; neither replaces the other, and they share no ids.

Names

gates/deploy and gates/merge are the names to use. /quality-gates and /ci/gates are the original paths; they keep working and return the same results as their new names (POST, GET, DELETE /{id} and, for merge gates, POST /{id}/evaluate). The OpenAPI document and generated clients still list the original paths, so the two names can never differ in a client.

Updated