Record image pin and remaining apply step (REUSE-WP-0020-T05)
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s
ci / validate-registry (push) Successful in 1m35s

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-08-21 00:18:03 +02:00
parent 3aaf961352
commit 3b46fd747f

View file

@ -161,7 +161,7 @@ hardened, re-enable and confirm `/v1/federated` returns 61 sources.
```task
id: REUSE-WP-0020-T05
status: todo
status: progress
priority: high
```
@ -183,21 +183,33 @@ Deadline-bound: must land before **2026-08-31**.
2. Bump `image.tag` in `railiance-apps/helm/reuse-surface-values.yaml` from
`e3ae22e` to a verified Forgejo tag.
**Prefer a build of current HEAD over `main-f9d957a`.** T02's compose
hardening is not in `main-f9d957a`, and without it re-enabling
`evidence-binder` (T04) would take production to HTTP 500 again. Pushing
HEAD touches `reuse_surface/**`, so CI will produce `main-<short-sha>`;
deploy that tag. Not pushed yet — pushing to the shared remote needs an
explicit go-ahead.
**Done 2026-08-20**`railiance-apps@029460d` pins `main-b035664`, verified
to resolve (manifest `200`). CI built it after `fix-consistency` pushed the
T02/T08 commits. It carries the compose hardening, which `main-f9d957a` does
not: without it, re-enabling `evidence-binder` (T04) would take production
back to HTTP 500.
Left deliberately unmodified for now: writing a tag that has not been built
is worse than leaving the current wrong one, since it converts a latent
failure into an immediate one on the next reconcile.
3. Correct `docs/deploy/reuse-kubernetes.md`, which still describes Gitea as
the live registry and its manual `docker build`/`push` commands still
target `gitea.coulomb.social`.
4. Apply from a host with cluster access; verify rollout, `/v1/federated`,
and that the PVC at `/data` survived.
Committed but **not applied**. `railiance-apps` has no ArgoCD or Flux
controller, so a commit there deploys nothing — `make reuse-deploy` is a
manual `helm upgrade` requiring `REUSE_KUBECONFIG` for Railiance01.
3. ~~Correct `docs/deploy/reuse-kubernetes.md`.~~ **Done 2026-08-20** (`b035664`).
4. **Remaining.** Apply from a host with cluster access — the workstation
kubeconfig points at `127.0.0.1:16443` and needs an ops-bridge tunnel:
```bash
make reuse-dry-run # helm template, no apply
make reuse-deploy # helm upgrade --install --wait
make reuse-status # pods, svc, ingress, pvc, certificate
curl -s https://reuse.coulomb.social/v1/federated | head -c 300
curl -s https://reuse.coulomb.social/v1/reuse-events # 404 today; 200 proves T04/T05 shipped
```
Confirm the PVC at `/data` survived, since `reuse.db` and the remote index
cache live there.
**`make reuse-smoke` will fail** — it runs `curl -fsS $(REUSE_URL)/health`,
and `/health` returns nginx `404` through the ingress (see T06). Fix that
first or expect a false negative on an otherwise good deploy.
Ships REUSE-WP-0019 **T04/T05/T06** as a side effect — telemetry store,
R-axis aggregation, and hub freshness monitoring were closed as finished but