mhoennigandClaude Opus 5
25c0eb94b6
The old bash script configured itself through `GITTALLY_*` environment variables. The blanket rename rewrote those literals, so the converter was looking for `WERKATOR_*` — a spelling no host has ever written. Fed a real legacy file it would have found nothing and written an almost empty configuration, without an error, which is the same silent failure this rename is otherwise careful to avoid. The conversion has served its purpose with the vm2176 to vm4006 migration, so it goes instead of being repaired. What remains is the setup of a new instance: the preconditions, the credential prompt, and the machine configuration written mode 600 — now carrying the host's public URL as well, since that is host-specific too. Everything the repository builds comes from `init` and its templates. It also stops emitting a legacy `branches:` section, which step 18 is about to reject outright. `docs/plan/00-legacy-analysis.md` and `13-nginx-tls.md` get the real `GITTALLY_*` spelling back: they record what the old script read. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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