Files

T

mhoennigandClaude Fable 5 40f54a1298 Record builds interrupted by a server shutdown as INTERRUPTED, not FAILED

A systemd stop killed the running build process and BuildExecutor
classified the death as FAILED, posting a red Gitea status; FAILED is
not restartable, so the startup recovery never re-enqueued the build.

A ContextClosedEvent listener now sets a shuttingDown flag, terminates
the process trees of executing builds, and drains until their
INTERRUPTED results are persisted. Queued builds stay PENDING without
starting a process; recovery re-enqueues both after the restart.
INTERRUPTED publishes as Gitea state "pending" instead of "failure",
since the build is going to be re-run.

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

2026-08-10 17:26:10 +02:00

2026-07-08-PR#000-age-based-artifact-retention.md

added age-based build retention: artifacts.retentionMaxAge (e.g. 30d, empty = no limit) drops builds older than the given age; combines with retentionPerBranch as independent caps — a build is kept only while it satisfies both limits; a branch's newest build is never age-pruned and keepLatestGreen now shields the latest green build from both limits, keeping the permanent /branches/... links valid

2026-07-08 22:35:31 +02:00

2026-07-08-PR#000-build-only-pull-request-branches.md

made the pull-request gate configurable: added watcher.pullRequestGate (default true); set false for plain-git origins without pull-request refs, so requirePullRequest gates are ignored and gated branches build on new commits; added the PR-doc

2026-07-08 15:50:45 +02:00

2026-07-08-PR#000-permanent-artifact-links-for-latest-green-builds.md

added permanent artifact links for latest green builds: /branches/<branch-key>/... serves the latest green build's artifacts (green-only, resolved per request), keepLatestGreen retention protection, permanent artifact-index page, and latestGreenUrl links in the branches view

2026-07-08 15:35:16 +02:00

2026-07-08-PR#000-security-audit-hardening.md

Added worktree-layered build config: resolves .gittally.yml from the worktree for per-branch build settings, with precedence worktree > .git > project; pinned secrets, server-side keys, and sandbox policy to .git.

2026-07-09 09:20:34 +02:00

2026-08-10-PR#000-interrupt-builds-on-server-shutdown.md

Record builds interrupted by a server shutdown as INTERRUPTED, not FAILED

2026-08-10 17:26:10 +02:00

README.md

added PR documentation guidelines and template: introduced docs/prs/README.md and TEAMPLATE.md

2026-07-08 07:03:17 +02:00

TEAMPLATE.md

added .claude/skills: introduced on-demand skill guides for architecture, PR documentation, and testing conventions; updated AGENTS.md to reference new skills

2026-07-08 15:20:37 +02:00

README.md

Pull-Request Documentations in doc/PR

This directory contains documentation for each pull request (PR).

IMPORTANT: The PR-documentation documents the change which was applied in that PR. Such documentation might be outdated right after the next PR was merged. Historic PR-documentation is not maintained along with new PRs.

Naming Convention

YYYY-MM-DD-PR#999-short-description-of-pr

Date of the PR in the format YYYY-MM-DD
followed '-PR#' followed by the number of the pull request in GitEA,
a short description of the PR with dashes between the words,
'.md'

Yes, to get the PR-number, you need to open a pull request first, but initially prefix its title with WIP: to mark it as a work in progress until it is ready for review.

Guidelines

Documentations must be written in Markdown format.
Use Englisch, it's a public open source project.
Use clear and concise language and keep it short.
Include relevant details and context, explain the "why".
Mark reference to Taiga or any other tool that is not public as "Hostsharing-internal".
If necessary, copy important parts of the ticket description.
One sentence or statement per line to make diffs easier to read.

Structure

The main (##) sections have to appear in exactly this order, omitting sections which do not apply:

Related Links (optional)
The Problem (required)
Non-Goals (required)
The Scenarios (optional for maintenance or bug fixing PRs, required for features)
The Solution (required)
Open Questions (optional)
Additional Changes (optional)
Prerequisite PRs (optional)
Follow-up PRs (optional)
Attachments (optional)

For details, see template