Files
platform/deploy/2026.08.23.05.report.md
2026-08-23 18:48:57 +00:00

226 lines
11 KiB
Markdown

# 2026.08.23.05 — deploy report
**5 of 5 target hosts succeeded.** Two hosts skipped by design: `officer-dev` (the host running the
rollout) and `edge-pertento-bridge` (in the *Deliberately skipped* section of `docs/servers.md`).
Every target ended at `e15ab2303a17ed0e1d1cf59b35f34aec68875907` = `deploy/2026.08.23.05`, merged
`--ff-only` onto the tag itself. No host was left on the branch, and no host is a commit past the tag.
Schema evidence is per host, by query, below. `--force` was never used and was never needed.
---
## Per host
### `alpha` — succeeded
| | |
| --- | --- |
| Checkout (from PM2 `pm_cwd`) | `/home/pastilhas/officerdev/platform` |
| HEAD before | `ff647fba` (`deploy/2026.08.23.04`) |
| HEAD after | `e15ab230` (`deploy/2026.08.23.05`) |
| Tracked changes before | none |
| Untracked files | none |
Pre-check: `roles = 4`, orphan users `0`, orphan grants `0`.
SQL applied, exit 0. Verification query:
```
conname | pg_get_constraintdef
-------------------------------+-------------------------------------------------------------
ck_role_permissions_not_owner | CHECK ((role <> 'Super Admin'::text))
fk_role_permissions_role | FOREIGN KEY (role) REFERENCES roles(name) ON UPDATE CASCADE
fk_users_role | FOREIGN KEY (role) REFERENCES roles(name) ON UPDATE CASCADE
```
Both `fk_` present, `ON UPDATE CASCADE`, no `ON DELETE`. `ck_role_permissions_role` absent.
`ck_role_permissions_not_owner` present. Re-queried after `db:push` — unchanged.
`bun db:push` ran clean. **It is not a no-op on this host** — see "The one thing that is not clean" below.
`bun run plugins:update`: `12/12 updated in 47s`, exit 0. That step restarted twelve plugin sidecars —
atelier, bitcoin-wallet, email, gitea, invoices, jellyfin, music, offscale, photos, soulseek,
transmission, vault.
`pm2 restart officer`: restart_time 70 → 71, `online`. All 19 `officer*` processes `online` afterwards.
### `fofos` — succeeded
| | |
| --- | --- |
| Checkout | `/home/pastilhas/officerdev/platform` |
| HEAD before | `ff647fba` (`deploy/2026.08.23.04`) |
| HEAD after | `e15ab230` (`deploy/2026.08.23.05`) |
| Tracked changes before | none |
| Untracked files | `scripts/chk.ts` — left alone, not a reason to skip |
Pre-check: `roles = 4`, orphans `0` / `0`. SQL applied, exit 0. Verification query returned the same
three rows as `alpha`: both `fk_` present with `ON UPDATE CASCADE`, `ck_role_permissions_role` absent,
`ck_role_permissions_not_owner` present.
`bun db:push` clean; a second `push --verbose` said **`No changes detected`** — a genuine no-op.
`bun run plugins:update`: `1/1 updated in 7s`, exit 0. Restarted `officer-gitea`.
`pm2 restart officer`: 24 → 25, `online`. All 8 processes `online`.
### `production-pertento-bridge` — succeeded
| | |
| --- | --- |
| Checkout | `/home/pastilhas/officerdev/platform` |
| HEAD before | `ff647fba` (`deploy/2026.08.23.04`) |
| HEAD after | `e15ab230` (`deploy/2026.08.23.05`) |
| Tracked changes before | none |
| Untracked files | none |
Pre-check: `roles = 4`, orphans `0` / `0`. SQL applied, exit 0. Verification query: same three rows,
same verdict.
`bun db:push` clean; second `push --verbose` → **`No changes detected`**.
`bun run plugins:update`: `1/1 updated in 5s`, exit 0. Restarted `officer-gitea`.
`pm2 restart officer`: 3 → 4, `online`. All 15 processes `online` (this host also runs eight non-Officer
PM2 entries — Crons/Dashboard/Tracking/Uptime — untouched and still `online`).
Cosmetic, pre-existing, not caused by this release: every `$SHELL -ic` command on this host prints an
nvm warning about a `globalconfig`/`prefix` in `~/.npmrc`. Nothing failed because of it.
### `deadpool-rezio-bridge` — succeeded
Login `br`, per `docs/servers.md`.
| | |
| --- | --- |
| Checkout | `/home/br/officerdev/platform` |
| HEAD before | `ff647fba` (`deploy/2026.08.23.04`) |
| HEAD after | `e15ab230` (`deploy/2026.08.23.05`) |
| Tracked changes before | none |
| Untracked files | none |
Pre-check: `roles = 4`, orphans `0` / `0`. SQL applied, exit 0. Verification query: same three rows,
same verdict.
`bun db:push` clean; second `push --verbose` → **`No changes detected`**.
`bun run plugins:update`: `2/2 updated in 7s`, exit 0. Restarted `officer-email` and `officer-offscale`.
`pm2 restart officer`: 9 → 10, `online`. All 9 processes `online`.
### `macbookpro` — succeeded, and the host the plan flagged is now verified
Awake and reachable. macOS, so the PATH and `psql` notes in `docs/servers.md` all applied.
| | |
| --- | --- |
| Checkout | `/Users/pastilhas/projects/officer-suite/platform` |
| HEAD before | `6e092c32` (`deploy/2026.08.23.04-48-g6e092c32`) |
| HEAD after | `e15ab230` (`deploy/2026.08.23.05`) |
| Tracked changes before | none |
| Untracked files | none |
It started 48 commits *past* the previous tag rather than on it — the tag was still an ancestor, so the
fast-forward was legitimate and no reset was needed.
**The roles table the plan could not verify before the tag is now verified:** `roles = 4`, orphan users
`0`, orphan grants `0`. The plan was right that there is no `psql` here — there is also no Homebrew
postgres and no postgres container. The query went through **Bun's own `SQL` client** (`bun 1.3.14`)
against the same `OFFICERDEV_POSTGRES_URL` the platform's `drizzle.config.ts` reads, so it is that host's
own database and not an inference from another one.
SQL applied through the same client, no exception raised. Verification query:
```json
[
{ "conname": "ck_role_permissions_not_owner",
"pg_get_constraintdef": "CHECK ((role <> 'Super Admin'::text))" },
{ "conname": "fk_role_permissions_role",
"pg_get_constraintdef": "FOREIGN KEY (role) REFERENCES roles(name) ON UPDATE CASCADE" },
{ "conname": "fk_users_role",
"pg_get_constraintdef": "FOREIGN KEY (role) REFERENCES roles(name) ON UPDATE CASCADE" }
]
```
Both `fk_` present with `ON UPDATE CASCADE` and no `ON DELETE`; `ck_role_permissions_role` absent;
`ck_role_permissions_not_owner` present. Same verdict as the other four.
`bun db:push` ran clean. It is not a no-op here either — see below.
`bun run plugins:update`: exit 0, and its whole output was **`no plugins installed — nothing to update`**.
No sidecar restarted. That is worth a second look and is covered below.
`pm2 restart officer`: 11 → 12, `online`. All 6 processes `online`.
---
## The one thing that is not clean
The plan says `bun db:push` should be a no-op after the SQL, and that anything it still wants to alter
means the SQL was incomplete. On two hosts it still wants to alter something. **It is not the release's
schema change, and the SQL was not incomplete** — the verification query above proves the constraints
this release introduced are exactly right on all five hosts, and re-querying after `push` on `alpha`
showed them unchanged.
What `push --verbose` still wants, after the SQL:
- **`alpha`** — drops and immediately re-adds `pk_music_now_playing` on `music_now_playing`, with an
identical definition.
- **`macbookpro`** — the same `music_now_playing` churn, plus two `atelier_collection_items` foreign
keys dropped and re-added under names one character longer (`…_id_f` → `…_id_fk`).
Both are plugin tables, both are the documented drizzle-kit mis-diff on named composite constraints and
on foreign keys whose generated name Postgres truncates at 63 characters. The `atelier` case is
precisely the churn this release's notes claim to end "across the fleet's plugins" — and on `alpha`,
where the plugins *did* update, the atelier churn is indeed gone and only the `music` one remains. On
`macbookpro` the plugins did not update at all, so it still carries both.
`fofos`, `production-pertento-bridge` and `deadpool-rezio-bridge` all reported `No changes detected` —
a true no-op, which is the outcome the plan expected.
I judged this not to be a stop condition and continued. The reasoning, so it can be overruled: the plan's
"stop and report" is aimed at the roles/FK change being half-applied, that change is provably whole on
every host, and the residue is a pre-existing self-cancelling churn on plugin tables that this release
does not touch. If that call was wrong, the thing to re-examine is `music_now_playing`'s composite
primary key — it is the one still churning on the host where plugins are current.
---
## What I did not do, and could not verify
- **`officer-dev` — skipped entirely.** Not pulled, nothing restarted. It is at `6cd99ddb`, one commit
*past* the tag; that commit landed on `master` after the tag was cut and is a docs commit. Its schema
change was already applied and verified before this rollout, per the plan. It is the only host not at
the tag exactly, and restarting it is the owner's deliberate last step.
- **`edge-pertento-bridge` — skipped, not a failure.** Listed in *Deliberately skipped* since
2026-08-23. Nothing was spent on it: no SSH attempt, no retry.
- **The five-language picker was NOT checked in a browser.** The plan's "what to check" asks for the
profile settings picker to offer five languages and for a *panel* to be inspected in a non-English
locale. That is a UI check and I did not perform it. What I can say is narrower: every host serves the
tag's bundle and every host restarted `officer` afterwards, so the fix is present in the code each
host is running. Whether it renders is unconfirmed.
- **Minesweeper's absence was not checked.** `/minesweeper` was not requested on any host, and the dock
was not inspected.
- **`macbookpro` reports no plugins installed** while `gen-plugin-schemas` finds three schema files on
disk (`atelier`, `kiosk`, `music`). So that host has plugin *schemas* without registered plugins. This
predates the release and nothing in the plan covers it, so I left it alone — but it explains why the
atelier constraint churn cleared on `alpha` and not here, and it means `macbookpro`'s plugins are not
being updated by the deploy at all.
- **`plugins:update` restarted sidecars on four hosts before the plan's own restart step**, as
`docs/servers.md` warns. Counted per host above rather than left as "restarted: officer".
## One note for `docs/servers.md`
The database URL key is **not the same on every host.** `alpha` has only `POSTGRES_URL`; `fofos`,
`production-pertento-bridge`, `deadpool-rezio-bridge` and `macbookpro` have only
`OFFICERDEV_POSTGRES_URL`. `drizzle.config.ts` reads `OFFICERDEV_POSTGRES_URL ?? POSTGRES_URL`, so both
work for the app — but a rollout that queries the database directly must follow the same precedence or
it verifies the wrong database and says "schema ✓" about it. This cost one failed step on `fofos` before
being caught, and I re-checked `alpha` afterwards to confirm it holds only the one key and that its
verification was therefore sound.
`macbookpro` also has no `timeout(1)`. A remote command wrapping anything in `timeout` fails there with
`command not found` — and it fails *silently* in the sense that what you see is the next command's error,
not the missing binary's.