mi/werkator
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

renaming from gitTally to Werkator

Browse Source
This commit is contained in:
mhoennig
2026-08-30 18:35:49 +02:00
parent 4d76744721
commit 7f550689dd
169 changed files with 1361 additions and 7504 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/bootstrapping.md
+23 -23
View File
@@ -1,6 +1,6 @@
# GitTally Bootstrapping
# werkator Bootstrapping
Bootstrapping prepares a git repository for use with GitTally.
Bootstrapping prepares a git repository for use with werkator.
It creates the config files described in [configuration.md](configuration.md).
With `init --systemd` it also generates a systemd user unit for running the server permanently, see [deployment.md](deployment.md).
@@ -14,7 +14,7 @@ Run `init` once per repository, from within a checked-out working tree.
## Running `init`
First, in `<gittally-root>`, build the application to generate the executable JAR file:
First, in `<werkator-root>`, build the application to generate the executable JAR file:
```bash
./gradlew build
@@ -23,21 +23,21 @@ First, in `<gittally-root>`, build the application to generate the executable JA
Then run `init` using the generated JAR (not the `-plain.jar`):
```bash
java -jar <gittally-root>/build/libs/gittally.jar init
java -jar <werkator-root>/build/libs/werkator.jar init
```
`init` performs the following steps in order:
### 1. Detect the Repository Root
GitTally resolves the repository root by running `git rev-parse --show-toplevel`.
werkator resolves the repository root by running `git rev-parse --show-toplevel`.
If the current directory is not inside a git repository, `init` exits with an error.
### 2. Auto-detect Gitea Connection from `origin`
If `gitea.baseUrl`, `gitea.owner`, and `gitea.repo` are already set in `.gittally.yml`, these values are used.
If `gitea.baseUrl`, `gitea.owner`, and `gitea.repo` are already set in `.werkator.yml`, these values are used.
Otherwise, GitTally inspects the `origin` remote URL and derives the Gitea connection defaults:
Otherwise, werkator inspects the `origin` remote URL and derives the Gitea connection defaults:
| Origin URL form | Detected values |
|--------------------------------------------|----------------------------------------|
@@ -52,7 +52,7 @@ The `.git` suffix is stripped from the repo name. The username embedded in HTTPS
### 3. Create the Repo-Install Config
Creates `.git/gittally/.gittally.yml` (and its parent directory if needed).
Creates `.git/werkator/.werkator.yml` (and its parent directory if needed).
This file is **never committed** to the repository and is used for all branches,
as long as not overridden by a project config.
@@ -68,7 +68,7 @@ git:
### 4. Create the Branch/Project Config
Creates `.gittally.yml` in the repository root with project-level defaults.
Creates `.werkator.yml` in the repository root with project-level defaults.
If the file already exists, `init` prints a notice and leaves it untouched.
@@ -84,55 +84,55 @@ gitea:
...
```
Then, you have to configure *gitTally* by amending this config file according to [configuration.md](configuration.md).
Then, you have to configure *werkator* by amending this config file according to [configuration.md](configuration.md).
## Output
`init` prints one line per action taken:
```
created .git/gittally/.gittally.yml
created .gittally.yml
created .git/werkator/.werkator.yml
created .werkator.yml
```
Or, when files already exist:
```
.git/gittally/.gittally.yml already exists — not overwritten
.gittally.yml already exists — not overwritten
.git/werkator/.werkator.yml already exists — not overwritten
.werkator.yml already exists — not overwritten
```
## Hosts Without a Java Runtime
GitTally is intended to run on Hostsharing Container Server environments, which provide Docker and git but no Java runtime.
werkator 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.
A containerized werkator runtime was considered and rejected there.
## Next Steps After `init`
1. Open `.git/gittally/.gittally.yml` and set `git.token` and `git.account`.
2. Review `.gittally.yml` and add/adjust any branch build settings.
1. Open `.git/werkator/.werkator.yml` and set `git.token` and `git.account`.
2. Review `.werkator.yml` and add/adjust any branch build settings.
3. Verify the effective configuration:
```bash
java -jar build/libs/gittally.jar config:print --full
java -jar build/libs/werkator.jar config:print --full
```
4. Start the server:
```bash
java -jar build/libs/gittally.jar server
java -jar build/libs/werkator.jar server
```
5. For permanent operation, install the systemd user service described in [deployment.md](deployment.md).
## Example: Test Server with a Fake Build
[examples/setup-gittally-testserver.sh](examples/setup-gittally-testserver.sh) starts a GitTally server against a scratch repository with a fake build — the setup used for the manual UI/API smoke tests during development.
[examples/setup-werkator-testserver.sh](examples/setup-werkator-testserver.sh) starts a werkator server against a scratch repository with a fake build — the setup used for the manual UI/API smoke tests during development.
It creates a local bare origin plus a `work` clone, commits a slow fake build script (live log output, demo report artifact) with a `pollInterval: 5s` config, and starts the server on port 18980.
The origin gets a second branch (`feature/demo`), so the Branches view shows more than one entry.
No Gitea, no credentials, no Docker; `INSTALL_DIR`, `SERVER_PORT`, and `BUILD_SECONDS` can be overridden via environment variables.
While the server runs, push empty commits from the `work` clone to trigger builds; a commit message containing `[fail]` makes the build fail, and pushing a new branch exercises the new-origin-branch path.
## Example: Self-Hosting GitTally
## Example: Self-Hosting werkator
[examples/setup-gittally-selfhost.sh](examples/setup-gittally-selfhost.sh) shows the full sequence as a runnable script: it sets up a GitTally instance that watches and builds GitTally itself.
[examples/setup-werkator-selfhost.sh](examples/setup-werkator-selfhost.sh) shows the full sequence as a runnable script: it sets up a werkator instance that watches and builds werkator itself.
Run it from a working checkout; it builds the JAR, creates a dedicated clone, runs `init`, writes the machine-specific config, and starts the server.
`INSTALL_DIR`, `ORIGIN_URL`, `SERVER_PORT`, `GIT_ACCOUNT`, and `GIT_TOKEN` can be overridden via environment variables.
The script also demonstrates the kick-start trick: resetting the local ref one commit behind origin makes the very first poll build immediately, instead of waiting for the next push.