How do I calibrate a CI gate before I let it block a merge?

Run it in report-only mode first and watch what it would have blocked before you let it block anything. Tessary’s CI gate ships with risk-threshold at 1.0, which disables the risk trigger outright, and block-on-regression at false, so a fresh install posts its verdict on every pull request without stopping a merge. Once you’ve watched it against enough real PRs to trust the forecast, lower the threshold in your project config so it starts blocking.

You don’t have to commit to a number blind, either. A single request to the gate’s report endpoint can pass a gate_threshold that overrides the config for that one PR, so you can try a stricter bar on one change and see what it would have caught before you redeploy the config for everyone. The gate blocks on two triggers, OR’d: predicted risk clearing your threshold, or a grader measurably regressing once block-on-regression is on.

keep reading

More on this.

Does production detection replace the pre-deploy gate?No, it feeds it. In Tessary a production classifier firing registers a pre-deploy check for that surface, opt-in and off until a project enables it.answer →How does a CI eval job avoid stacking a new comment on every push?It edits its own prior comment instead of posting a new one. Tessary's gate embeds a stable marker in the comment body so a workflow can find it.answer →What does an eval gate report when a PR has no baseline run?A one-sided delta, not a zero. When one side of a PR has no completed eval run, Tessary's gate reports the gap instead of treating it as a pass.answer →Everything on deploy gatesThe definition, and every question answered under deploy gates.concept →

Send us the traces you already emit.

book a demo