| Comment: | deploy: Dockerfile, compose stack and a run book
quarry had no packaging at all while notify already had a working Dockerfile and compose. The image ships zit WITH quarry, deliberately: 0001 §2 makes the zit CLI the entire store interface, so zit's behaviour IS quarry's, and today alone three zit builds changed what quarry does — frames got faster, a card fix changed which artifacts parse, stat -R enabled bare-store serving. ZIT_REF is a build argument and /etc/quarry-build records the pair, so a container can answer which zit it carries. compose follows notify's shape, including the constraint its own file documents: dagnats binds loopback in standalone mode, so everything shares its network namespace. quarry joins it too — its embedded NATS uses DontListen and binds nothing, so there is no port to collide with. docs/running.md is the by-hand path, which is what this was actually developed against: the launchd-signed dagnats, notify's bootstrap and workflows, the topic-vs-subscriber addressing, and the two credentials that close the write and push gates. Unverified, and said so in the doc: no container runtime is installed here, so the images have never been built. The two build recipes inside them ARE verified natively — zit compiles from a clean clone with zig build --release=fast, quarry builds fully static with CGO_ENABLED=0. Also lands the publish-throughput measurement as an opt-in test. It is what disproved the hypothesis that synchronous publish was the ingest bottleneck (62k msg/s sync), which redirected the search to zit frames and quarry's folding. |
|---|---|
| Timelines: | family | ancestors | descendants | both | trunk |
| Files: | files | file ages | folders |
| SHA3-256: |
bbe731e042e68686f9ea64c72d799af2 |
| User & Date: | dmestas on 2026-08-17 16:40:19.155 |
| Other Links: | manifest | tags |
|
2026-08-17
| ||
| 16:48 |
ignore generated fixture stores
fixtures/out is 599MB of built stores and it is what a 'zit addremove' once swept into this repository, along with a 45MB binary — 559MB of bloat that took a shun and a reclaim to undo. Ignoring the BUILT output rather than the whole directory: the scripts and README beside it are source. .zitignore rather than the ignore-glob setting, because zit says plainly that a root .zitignore overrides the setting, and because a tracked file travels with a clone while a local setting does not. check-in: 52a8ca8b77 user: dmestas tags: trunk | |
| 16:40 |
deploy: Dockerfile, compose stack and a run book
quarry had no packaging at all while notify already had a working Dockerfile and compose. The image ships zit WITH quarry, deliberately: 0001 §2 makes the zit CLI the entire store interface, so zit's behaviour IS quarry's, and today alone three zit builds changed what quarry does — frames got faster, a card fix changed which artifacts parse, stat -R enabled bare-store serving. ZIT_REF is a build argument and /etc/quarry-build records the pair, so a container can answer which zit it carries. compose follows notify's shape, including the constraint its own file documents: dagnats binds loopback in standalone mode, so everything shares its network namespace. quarry joins it too — its embedded NATS uses DontListen and binds nothing, so there is no port to collide with. docs/running.md is the by-hand path, which is what this was actually developed against: the launchd-signed dagnats, notify's bootstrap and workflows, the topic-vs-subscriber addressing, and the two credentials that close the write and push gates. Unverified, and said so in the doc: no container runtime is installed here, so the images have never been built. The two build recipes inside them ARE verified natively — zit compiles from a clean clone with zig build --release=fast, quarry builds fully static with CGO_ENABLED=0. Also lands the publish-throughput measurement as an opt-in test. It is what disproved the hypothesis that synchronous publish was the ingest bottleneck (62k msg/s sync), which redirected the search to zit frames and quarry's folding. check-in: bbe731e042 user: dmestas tags: trunk | |
| 16:35 |
archives: download a check-in as a tarball (blocked on zit#97)
zit#95 landed 'zit tarball', so quarry can offer what every forge does: this check-in as a file. An op, a download route with the same posture as attachments (always a download, never an inline render), and a link beside the clone box. It does not work yet, and the reason is upstream: zit tarball ignores -R and demands a checkout in the working directory, which a server process never has (zit#97). ls honours -R from the same directory against the same store; tarball does not. The route is correct and stays — it starts answering the moment the flag is honoured — and the failure is reported as unavailable rather than not-found, because the repository is there and the archive is what cannot be produced. Not worked around: 0001 §2 makes the CLI the whole store interface, and a checkout materialised per download to dodge the bug would defeat both that and the reproducibility the feature exists for. check-in: c81b757987 user: dmestas tags: trunk | |