Document the initial build burst after the first server start

Investigating six near-simultaneous builds on vm4006 showed no duplicate
enqueue: they were six distinct recently-active origin branches, each built
once by the documented new-origin-branch rule (in a fresh clone every origin
branch counts as new). The watcher already guards against duplicates per
branch and per commit, with test coverage; only the first-start behavior was
undocumented.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
mhoennig
2026-08-10 16:33:04 +02:00
co-authored by Claude Fable 5
parent 421d51063b
commit 4ca077da80
+3
View File
@@ -60,6 +60,9 @@ systemctl --user enable --now gittally-<repo-name>.service
The unit runs `java -jar ~/bin/gittally.jar server` with the repository as working directory and `Restart=always`. The unit runs `java -jar ~/bin/gittally.jar server` with the repository as working directory and `Restart=always`.
The unit name contains the repository name, so several repositories can be served by one host, each with its own service and port. The unit name contains the repository name, so several repositories can be served by one host, each with its own service and port.
Expect a burst of builds right after the very first start: in a fresh clone every origin branch counts as new, so each branch with commits younger than `watcher.newBranchMaxAge` (default 5d) is built once — one build per branch, executed serially up to `builds.maxConcurrent`.
Lower `watcher.newBranchMaxAge` before the first start, or enable `requirePullRequest`, to limit the initial backlog.
User services stop at logout unless lingering is enabled once per user: User services stop at logout unless lingering is enabled once per user:
```bash ```bash