Trevin Chow
8bab997854
Without this config, Greptile's documented default is `triggerOnUpdates: false` (only the initial PR open triggers a review). Empirically Greptile has been re-reviewing on force-push to this repo anyway, but documenting the intent makes the behavior reliable across plan changes and any future config-source shifts on Greptile's side. `statusCheck: true` registers Greptile as a GitHub status check (not just a PR comment). That gives maintainer-tooling a machine-readable heartbeat - poll `GET /repos/.../commits/SHA/check-runs` and filter by app name to see whether Greptile is `queued` / `in_progress` / `completed`. Without it the only signal is "did a new Greptile comment appear" which is silently ambiguous when Greptile re-reviews and finds nothing new. If `statusCheck` is OSS-plan-restricted Greptile silently ignores the key, which is fine - the rolling-summary comment with `Confidence Score: N/5` remains the fallback signal. Refs greptileai/skills `greploop` skill for the terminal-state pattern this config enables.
5 lines
54 B
JSON
5 lines
54 B
JSON
{
|
|
"triggerOnUpdates": true,
|
|
"statusCheck": true
|
|
}
|