From 4ca077da80b558fa41400f2fc748cbf6972b4e71 Mon Sep 17 00:00:00 2001 From: mhoennig Date: Mon, 10 Aug 2026 16:33:04 +0200 Subject: [PATCH] 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 --- docs/deployment.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/docs/deployment.md b/docs/deployment.md index 0f8eb3e..b9a5689 100644 --- a/docs/deployment.md +++ b/docs/deployment.md @@ -60,6 +60,9 @@ systemctl --user enable --now gittally-.service 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. +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: ```bash