1n40varqdkk40uerb6h64frqr30ukl2a · 12 rows
| key | value |
|---|---|
| auto_compact_enabled | false |
| compact_batch_size | 50 |
| compact_parallel_workers | 5 |
| compact_tier1_days | 30 |
| compact_tier1_dep_levels | 2 |
| compact_tier2_commits | 100 |
| compact_tier2_days | 90 |
| compact_tier2_dep_levels | 5 |
| compaction_enabled | false |
| issue_prefix | sr-ht-ecore |
| kv.memory.ecore-architecture | `sourcecraft.dev/bigbes/sr-ht-ecore` holds everything the six custom services of the self-hosted SourceHut instance share that is *ours* rather than upstream's, so the `sr-ht-core` fork stays a clean mirror of core-go. Thirteen packages as of 2026-08-09: `chrome` (nav, brand, page partials, listing partials), `grants`, `bearer` (+ `StatusFor`/`Challenge`/`IsRefusal`), `pages` (page sets, buffered render, error page, `FormValues`), `assets` (hashed assets, `DirFS`), `csrf`, `middleware` (cache policy, panic recovery, 499), `login` (unified-login cookie decode), `internalauth` (both ends of `Authorization: Internal`), `instconf` (origin canonicalisation, `Require`), `logging` (slog policy without the handler), `chimw` (chi-shaped helpers), `ecoretest`. **This reverses the family convention still written in the services' Russian SPEC/DESIGN docs** ("копируем, не выносим в общий модуль; единственная общая зависимость — sr-ht-core"). The user confirmed the reversal is deliberate and those documents are not to be corrected. There are two shared modules now: `sr-ht-ecore` and `go.bigb.es/auxilia`. Boundaries settled by argument, not taste: - ecore does **not** depend on auxilia. `logging` ships the mask policy and a stdlib `ReplaceAttr`; the service picks the handler (scribe's tint on this instance). - `middleware` stays dependency-free (net/http only); anything chi-shaped goes in `chimw`. - A general logging adapter belongs in auxilia, not ecore — ecore is SourceHut-specific. That is why `logrusbridge` landed in auxilia. - `middleware.RecoverPanics` logs through `slog.Default()`, which is what gives ecore a stake in every service calling `slog.SetDefault` — hence `logging` existing at all. `chrome.BuildNav` is only half of the instance's service switcher: the Python services render the same strip from `core.sr.ht/srht/app/flask.py`, which orders the non-canonical half by config-file order rather than alphabetically, and whose `nav.html` excludes hub from the loop exactly as `navExcluded` does. Changing the ordering or the exclusions here makes the two halves disagree — see [[srht-instance-deploy]] for why the config file is written alphabetically. The alphabetical tiebreak is forced, not chosen: `ini.File` is a `map[string]Section`, so core-go's parser has already thrown the file order away by the time `BuildNav` sees it, and matching upstream exactly would mean re-scanning the config for `[section]` lines. Two more divergences from `nav.html`, neither of them ordering: `BuildNav` skips a section with no `origin` (upstream lists it, with a broken href), and it resolves every origin once at startup where upstream calls `get_origin` per render. Upstream is readable locally — the whole fleet is checked out under `~/data/home/sourcehut/` (`core.sr.ht`, `git.sr.ht`, …) — so answer "what does upstream actually do" from the source rather than from the comments in our copies. `chrome.Page` embeds as the field name `Page`, so a view struct wanting `Page` for its own payload must rename it. Listing columns (`Updated`, `Meta`) are optional on purpose: bench and spec needed them, dolt has no timestamp in its schema, cover's table of sparklines fits no shared partial. |
| kv.memory.srht-instance-deploy | The stack lives in `~/data/home/phoebe-lab/srht` and deploys with **`labng push srht`** (`lab` is blocked by a hook). Its `post_push` in `deploy.yml` builds `srht-base`, runs `docker compose build` and `up -d` on phoebe — so a push *is* a deploy. Order that works, from a service commit to a running container: 1. push the service repo → builds.sr.ht packages it 2. **wait for `apk-mirror` to re-index** — until then `apk add pkg=<ver>` inside `docker compose build` dies with "unable to select packages" and `labng push` fails halfway. Poll it the way the build will see it, i.e. against the signed index and from phoebe (`repo.bigb.es` is LAN-only behind Authelia; from the mac even `APKINDEX.tar.gz` is a 302): ssh phoebe.lab.local "docker run --rm -v /data/containers/srht/keys:/keys:ro alpine:3.22 sh -c \ 'cp /keys/*.rsa.pub /etc/apk/keys/; echo https://repo.bigb.es/alpine/v3.22/bigbes >> /etc/apk/repositories; \ apk update >/dev/null 2>&1; apk list 2>/dev/null | grep <pkg>-<ver>'" 3. set the pin in `versions.env`, commit, `labng push srht` **Restart everything after editing `config.ini.tmpl`.** A config change with no restart shows up as a nav that still lists the old service. `docker compose restart meta todo builds git hub paste pages diff cov bench dolt spec tokens`. There is only **one** config file: `config-init` renders the template into the named volume `srht-config`, mounted `:ro` into every container. So two services showing *different* navs never means different files — it means different snapshot generations in memory. The Go services freeze theirs in `chrome.NewService` at process start; the Python ones compute `_network` at module import, and `scripts/entrypoint.sh` execs gunicorn **without `--preload`**, so that import runs in each worker after fork — a respawned worker can hold a newer config than its siblings, and than the Go services. Diagnose a nav listing a removed service with the file first and the process age second: docker compose exec <svc> grep -n 'man.sr.ht' /etc/sr.ht/config.ini docker compose ps --format '{{.Service}}\t{{.Status}}' Custom-service sections in `config.ini.tmpl` are written **alphabetically on purpose**: the Python sort is stable with one key, so it emits them in file order, while `chrome.BuildNav` sorts them by name — alphabetical file order is what makes the two navs agree. A new service goes in at its alphabetical place. `labng diff srht` **errors out on a file that does not exist on the remote yet** ("sync: download …: file does not exist") — that is the diff path only; `labng push` is fine and creates the file. `docker compose config` re-escapes a literal `$` on output, so `$${1}` in a traefik label prints back as `$${1}` — it is not proof that interpolation is wrong. **phoebe-lab is a shared repository: another session is usually working in it.** Twice in one session a parallel `git commit -a` swept my uncommitted edits into its own commit (`srht: disable man.sr.ht`), and later commits appeared on top of mine between a push and a status check. Stage only your own paths, and check `git log @{u}..` before saying anything about what is published — most of what is unpushed there is not yours. |