dlhufoubn2kucg4clrlaruv44npkcqto · 13 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-service-release | Releasing one of the six custom services (`sr-ht-{tokens,bench,cover,compare,dolt,spec}`) is **pushing a `vX.Y.Z` tag to the srht mirror**. There is no other step that produces a versioned apk. The chain: tag on `git.srht.bigb.es` → builds.sr.ht runs `.build.yml` → `abuild` → rclone to the Garage bucket → `apk-mirror` on phoebe re-indexes **every 15 minutes** (so a fresh apk is fetchable by exact URL immediately but invisible to `apk add` until the index lands). Three preconditions, all verified working as of 2026-08-09: - `.build.yml` `submitter.allow-refs` must list `"refs/tags/v*"` — without it a pushed tag starts no build at all. - The `version` task derives the version from one `git describe`: tag → `0.9.1`, tag plus commits → `0.9.1_git6` (sorts *after* the release in Alpine's grammar), no tag → `0.0.<commit count>`. - The version reaches `abuild` by **exported `PKGVER`**, never by `sed` of the tracked `APKBUILD` — see [[go-vcs-stamp-dirty]]. Tags push to `srht`, not only to `origin` (sourcecraft): gitsync mirrors branches, not tags. `compare` and `dolt` have no local `srht` remote — use `git@git.srht.bigb.es:~bigbes/sr-ht-<name>` directly. **dolt's tag has a deploy consequence**: the `dolt.sr.ht-hook` subpackage is built from the same APKBUILD, so the first tag renames it from `dolt.sr.ht-hook-0.0.<n>` to `dolt.sr.ht-hook-<tag>`. The git.sr.ht container pins it by exact version through `SRHT_DOLT_VER` in `phoebe-lab/srht/versions.env`; bump both in one change or `apk add` fails with "unsatisfiable constraints". Deployed versions live in `phoebe-lab/srht/versions.env` (`SRHT_<NAME>_VER`). Publishing is upload-only, never delete: a bad apk can only be superseded, not withdrawn. |
| kv.memory.srht-service-rename | Done twice on 2026-08-09: `compare.sr.ht` → `diff.sr.ht`, `cover.sr.ht` → `cov.sr.ht`. The repository, the Go module path, the binary and the URL routes were deliberately left alone both times — renaming them rewrites an import path and a repository URL for a word. **Everything the name actually lives in:** - service repo: `service.ConfigSection` (or `configSection` in `web/`), `APKBUILD` pkgname, `Makefile` `SERVICE=`, `config.example.ini`, `contrib/<name>.sr.ht.conf` + `contrib/<name>-srht.service` (rename the files), `.build.yml` (its own origin env var), `scss/main.scss`, docs - `phoebe-lab/srht`: `[<name>.sr.ht]` section + origin + connection-string in `config/config.ini.tmpl`, `Dockerfile.<name>` (+ `ARG SRHT_<NAME>_VER` and the `apk add` package), `scripts/entrypoint-<name>.sh`, compose service + hostname + traefik routers, `versions.env` var, `deploy.yml` file list, `scripts/init-db.sh` service list, `scripts/{check-versions,changelog}.sh`, `[git.sr.ht] extra-repo-tabs` - `sr-ht-ecore`: `ecoretest.customSections` **The two that break things silently:** 1. **Grant vocabulary.** `cover:upload` → `cov:upload` invalidates every issued token — grants are compared literally. The CI secret is shared (`~/.srht-token` carries both `cov:upload` and `bench:upload`), and it cannot be edited in place, see [[builds-srht-secrets]]. The build fails on the upload task only, everything else stays green. 2. **The mint form's checkbox list is a copy inside tokens.sr.ht** (`sourcehut-tokens/web/tokens.go`, `grantVocabulary`). The daemon validates no vocabulary, so it keeps offering the old grant after the service stops accepting it — the resulting token mints fine and admits nobody. Renaming a grant means a tokens.sr.ht release too. Its free-text field can mint the new grant meanwhile. **Postgres** (when the DB is renamed with the service): stop the container first, dump, then `ALTER DATABASE "old" RENAME TO "new"; ALTER ROLE old RENAME TO new; ALTER ROLE new WITH PASSWORD '<same>';` — the password reset is cheap insurance against md5-derived verifiers. **Old host keeps answering** through a second traefik router on the same service with `redirectregex` (`replacement: https://new.$${1}` — `$$` is compose's escape). Good for badges and links; useless for uploads, because `curl -X POST` in `.build.yml` has no `-L`. So the CI manifest must name the new origin in the same commit. Renaming a compose service leaves the **old container running as an orphan**, labels and all — `docker compose up -d` does not remove it, and its traefik labels then fight the new redirect router for the old host. `docker rm -f srht-<old>-1` after the deploy. Section order in `config.ini.tmpl` is alphabetical and load-bearing — see [[srht-instance-deploy]]. |