{
"name": "quarry",
"version": "1.0",
"_comment": "RETRY: none. dagnats counts max_attempts as retries after the first run (it retries while attempts <= max_attempts), so 0 means each step runs once: a red test, race, format or build is a verdict, and re-running it hid flakes and spent runner slots on check-ins already known to fail. The trouble retries existed for is the clone: each step fetches its check-in from this forge and a deploy restarts it (measured downtime 17.6s, and the clone takes ~14s to give up), so the runner retries the checkout itself (5s, 15s, 45s) before the command runs. TIMEOUT: a step registered with timeout 0 never times out, so a run whose task type no worker serves sits queued forever and reads 'running' \u2014 synthetic had one doing that for four days. 20m is well past the slowest step here (~6m). RUNNER: steps publish to worker group quarry and are claimed by `quarry runner` on the box, which runs what ci/runner.json names at the check-in under test.",
"steps": [
{
"id": "test",
"task": "quarry.test",
"timeout": 1200000000000,
"retry": {
"max_attempts": 0
},
"worker_group": "quarry"
},
{
"id": "fmt",
"task": "quarry.fmt",
"timeout": 1200000000000,
"retry": {
"max_attempts": 0
},
"worker_group": "quarry"
},
{
"id": "build",
"task": "quarry.build",
"timeout": 1200000000000,
"retry": {
"max_attempts": 0
},
"worker_group": "quarry"
}
]
}