alexion
0cbfe43ae0
All checks were successful
CI / test (push) Successful in 55s
Add the design record for distributing gitea-axi as a Nix flake: a package, a development shell, and a checks output, plus the continuous integration changes that come with it. ADR 0018 records the wrapper's deference to the operator's own `git` and `tea` — the reverse of the hermetic instinct, chosen because `tea` refreshes OAuth tokens in place and so must not have two versions mutating one credential store. Also records the `tea`-is-still-a-runtime-dependency gotcha, which ADR 0002's title obscures.
28 lines
2.1 KiB
Markdown
28 lines
2.1 KiB
Markdown
---
|
|
spec: nix-flake-packaging
|
|
---
|
|
|
|
## What to build
|
|
|
|
The packaging tier today holds two kinds of assertion joined only by an expensive shared setup step: assertions about the shape of the packed tarball and its manifest, and assertions that drive the resulting installed binary.
|
|
Split them, and teach the second group to accept the path of the binary to drive from the environment.
|
|
|
|
When the environment names an already-installed binary, the tier drives that binary directly and skips the pack-and-install setup entirely.
|
|
When it does not, the tier packs and installs exactly as it does today and drives the result.
|
|
This makes one seam that both the npm distribution path and — later — the Nix installation path call, so the two cannot drift apart in what they guarantee about an installed gitea-axi.
|
|
|
|
The tarball-shape assertions stay npm-only, since a Nix installation produces no tarball and no packed manifest.
|
|
|
|
The assertions themselves do not change in character: they drive a real subprocess, answer its HTTP calls with the in-process fixture server used throughout the suite, and point the `setup` command at a temporary home directory to observe the Agent Skill being written.
|
|
This tier deliberately inherits the parent environment, unlike the in-process CLI-seam harness — the spawned binary genuinely needs it.
|
|
|
|
Nothing may assert on store paths, wrapper internals, or the arrangement of files within the installed tree; those are implementation detail of the installation method.
|
|
|
|
## Acceptance criteria
|
|
|
|
- [ ] The installed-binary assertions live separately from the tarball-shape assertions, and both still run under the packaging tier's own runner configuration.
|
|
- [ ] An environment variable naming an existing binary makes the installed-binary group drive that binary and skip pack-and-install.
|
|
- [ ] With that variable unset, the group packs, installs, and drives the result as before — the default developer experience is unchanged.
|
|
- [ ] The full packaging tier passes in both modes.
|
|
- [ ] No assertion in the installed-binary group depends on how the binary was installed.
|