2.3 KiB
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
werkator init and tools/remote overlap: both write the machine config — init as a commented template, the script by appending heredoc blocks and patching values with sed.
The script re-implements configuration knowledge Werkator already owns (YAML shape, indentation, key names) outside the three-places sync invariant; an indentation mismatch in one append guard produced nine duplicate bwrap blocks on mih34 (step 21 session D) before it was found.
Smaller duplications of the same kind: the script re-implements control-token generation in bash, and check-prerequisites still pipes a bash script whose generic half now exists as werkdock doctor.
Non-Goals
- Implementing the change — this PR is the plan only; PR #9 implements it.
- Multi-repository support for one Werkator instance (step 22, PR #10).
The Solution
docs/plan/23-init-owns-the-files.md records the decision: Werkator becomes the executing app wherever possible, tools/remote shrinks to a wrapper.
Parameters travel as files, each side getting the format native to it: the wrapper keeps a small env file with transport-only values (--env-file FILE, mirroring Docker's flag naming since --env there means a single variable); Werkator takes a YAML fragment in its own config schema, applied via a new init --apply FILE, validated by the existing schema binding and needing no separate mapping table.
The plan was refined once during review: the first sketch proposed an env-file-only transport; the fragment being a first-class YAML file in Werkator's own schema replaced that, so there is no env-key-to-config-key conversion table to maintain at all.
Three sessions are laid out: A (Werkator side: init --apply, control-token subcommand), B (wrapper side: tools/remote loses its heredocs), C (live verification on mih34 and doc updates).
Prerequisite PRs
- PR #7 (webspace install path) — this plan corrects the remaining duplication that PR left in place.
Follow-up PRs
- PR #9: implements sessions A, B, and C of this plan.