Add self-contained runtime bundle distribution (jlink) for hosts without Java

./gradlew runtimeBundle packs a jlink-trimmed JRE, gittally.jar, and a
launcher script into one tarball, unpacked to ~/opt/gittally on the target
host; init --systemd works from the bundle unchanged because java.home and
the running-jar path resolve into it. Chosen over a GraalVM native image
(Spring AOT evaluates bean conditions at build time, which cannot represent
the dual-context CLI/server wiring) and over a containerized runtime — see
ADR 0006 and docs/plan/15-runtime-bundle-distribution.md, which also records
the full vm2176-to-vm4006 migration walkthrough.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
mhoennig
2026-08-10 15:35:35 +02:00
co-authored by Claude Fable 5
parent 8b71d0db8e
commit 9e7982ce34
9 changed files with 308 additions and 12 deletions
+4 -10
View File
@@ -102,17 +102,11 @@ Or, when files already exist:
.gittally.yml already exists — not overwritten
```
## Future: Docker-based Deployment
## Hosts Without a Java Runtime
GitTally is intended to run on Hostsharing Container Server environments, which provide Docker
but no Java runtime. A later development step will add a Docker image distribution where:
- GitTally itself runs as a Docker container (image bundles the JRE + JAR)
- Builds are spawned by mounting the host Docker socket (`/var/run/docker.sock`)
- `init` then optionally generates a `docker-compose.yml`, a secrets env file, and a systemd unit
that starts the Compose stack at boot
Until then, a Java runtime must be available on the host.
GitTally is intended to run on Hostsharing Container Server environments, which provide Docker and git but no Java runtime.
For these hosts, `./gradlew runtimeBundle` builds a self-contained runtime bundle (jlink-trimmed JRE + JAR + launcher) — see [deployment.md](deployment.md) and ADR 0006.
A containerized GitTally runtime was considered and rejected there.
## Next Steps After `init`