configurable build timeout #48

2026-09-10T08:55:20+02:00

mi commented

2026-09-10 08:55:20 +02:00

No description provided.

mi added 2 commits 2026-09-10 08:55:21 +02:00

build: stop a build that runs too long, and let the host cap it 907ecfa4e2

A hanging build held the only executor slot for 68 minutes on the production
instance at a system load of 0.17, with two other builds waiting behind it, and
nothing in Werkator would have ended it.

The host names the longest any build may run in executor.buildTimeout, 30
minutes by default. A build definition may ask for less in its own timeout, and
a longer wish is capped rather than refused — the rule is a minimum, not a
strip, which is why this is one of the few settings a branch may write: it can
promise to be quick, it cannot take the machine. One deadline covers the whole
build, not each command.

A build stopped this way is TIMED_OUT: not FAILED, because nothing about the
work failed, and not CANCELLED, because nobody decided to stop it. It is
terminal and not re-enqueued on its own, and Gitea sees a failure.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs: name PR#48 in the timeout documentation c8d14f2f0a

The PR-doc, the scenario IDs, the release-notes entry and the code
comments carried the PR#000 placeholder until the pull request existed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

mi merged commit da586f04c0 into main

2026-09-10 08:55:25 +02:00

mi deleted branch build-timeout

2026-09-10 08:55:25 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: mi/werkator#48