Install a nightly Docker cleanup timer with init --systemd (v0.9.7)

Port of the legacy host's docker-prune.timer: 02:00 host time,
Persistent=true, docker system prune -af — but without --volumes, so
the per-repository Gradle cache volumes survive. The units are
host-global; several GitTally instances share one timer.

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

docs/deployment.md

@@ -49,17 +49,29 @@ Generate the systemd user unit:
 java -jar ~/bin/gittally.jar init --systemd
 ```
 
-This writes `.git/gittally/gittally-<repo-name>.service` and `.git/gittally/gittally.env` and prints the install commands:
+This writes `.git/gittally/gittally-<repo-name>.service`, `.git/gittally/gittally.env`, and the nightly Docker cleanup units (`gittally-docker-prune.service`/`.timer`), and prints the install commands:
 
 ```bash
 ln -sf /path/to/repo/.git/gittally/gittally-<repo-name>.service ~/.config/systemd/user/gittally-<repo-name>.service
+ln -sf /path/to/repo/.git/gittally/gittally-docker-prune.service ~/.config/systemd/user/gittally-docker-prune.service
+ln -sf /path/to/repo/.git/gittally/gittally-docker-prune.timer ~/.config/systemd/user/gittally-docker-prune.timer
 systemctl --user daemon-reload
 systemctl --user enable --now gittally-<repo-name>.service
+systemctl --user enable --now gittally-docker-prune.timer
 ```
 
 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.
 
+### Nightly Docker Cleanup
+
+The `gittally-docker-prune.timer` runs `docker system prune -af` every night at 02:00 (host time), before the usual auto-build slots.
+It removes stopped containers, unused images, unused networks, and dangling build cache, so nightly builds start from freshly built images.
+Unlike the legacy cleanup it does **not** prune volumes — the per-repository Gradle cache volumes survive.
+The units are host-global (no repository name): with several GitTally instances on one host, every `init --systemd` generates the same files and the symlinks coincide.
+On hosts without a `docker` CLI the service is skipped, not failed (`ExecCondition`).
+`Persistent=true` catches up a missed run after downtime.
+
 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.
 

docs/prs/2026-08-10-PR#000-nightly-docker-prune-timer.md

@@ -0,0 +1,67 @@
+> **WARNING:** This document describes only the change applied in this PR.
+> It may already be outdated once the next PR is merged.
+> Historic PR-documentation is not maintained along with new PRs — treat it as a snapshot, not as current documentation.
+
+## The Problem
+
+The legacy host (vm2176) had a `docker-prune.timer` that cleaned up Docker every night at 02:00, before the nightly runs.
+Without it, unused images and stopped containers accumulate on the build host until the disk fills up.
+The rewrite did not port this timer, and it had to be installed by hand.
+
+## Non-Goals
+
+- No volume pruning: the legacy `docker system prune -af --volumes` would delete GitTally's per-repository Gradle cache volumes every night; the new cleanup keeps volumes.
+- No configurable schedule; 02:00 host time is hardcoded like on the legacy host.
+- No pruning from within the GitTally server process — the cleanup stays a plain systemd timer.
+
+## The Scenarios
+
+### Feature: nightly Docker cleanup installed with the service
+
+#### Background
+
+- The legacy unit (vm2176, Hostsharing-internal) ran `docker system prune -af --volumes` at 02:00 with `Persistent=true`.
+- GitTally's Docker builds maintain a per-repository Gradle cache volume that must survive a cleanup.
+
+#### Scenario#000.01: `init --systemd` generates the cleanup units alongside the service unit
+
+So that the cleanup is part of every GitTally installation instead of a manual step.
+
+- **Given** a repository initialized with `init --systemd`
+- **When** the generation finishes
+- **Then** `.git/gittally/gittally-docker-prune.service` and `.git/gittally/gittally-docker-prune.timer` exist
+  - **and** the printed install commands link and enable the timer together with the service
+
+##### Verified by
+
+- [InitCommandTest — "--systemd also generates the nightly Docker cleanup timer"](../../src/test/kotlin/de/hoennig/gittally/commands/InitCommandTest.kt)
+
+#### Scenario#000.02: The cleanup prunes containers and images but never volumes
+
+So that nightly builds start from fresh images while the Gradle caches survive.
+
+- **Given** the generated `gittally-docker-prune.service`
+- **When** the timer fires at 02:00 host time
+- **Then** it runs `docker system prune -af` (stopped containers, unused images, networks, dangling build cache)
+  - **and** it passes no `--volumes` flag
+  - **and** on hosts without a `docker` CLI the run is skipped, not failed
+
+##### Verified by
+
+- [SystemdServiceFilesTest — "prune service cleans containers and images but never volumes"](../../src/test/kotlin/de/hoennig/gittally/commands/SystemdServiceFilesTest.kt)
+- [SystemdServiceFilesTest — "prune timer fires nightly at 02:00 and catches up after downtime"](../../src/test/kotlin/de/hoennig/gittally/commands/SystemdServiceFilesTest.kt)
+
+## The Solution
+
+`SystemdServiceFiles` gets `pruneServiceContent()`/`pruneTimerContent()` next to the existing unit generation, and `createSystemdFiles` writes both files and extends the printed install commands.
+The unit names are host-global (`gittally-docker-prune.*`, no repository name): Docker is a host-wide resource, so several GitTally instances on one host share one timer — every `init --systemd` regenerates the same content and the symlinks coincide.
+Running containers and their images are never pruned by Docker, so an in-flight build is safe even if it overlaps 02:00.
+Documented in `docs/deployment.md` (section "Nightly Docker Cleanup").
+
+## Additional Changes
+
+- None.
+
+## Follow-up PRs
+
+- None planned.