deploy the tag, and stop spending a minute on a host that is known to be down
Two things the 2026.08.23.01 rollout showed. `edge-pertento-bridge` is down and staying down for some days, and the deploy agent had no way to know: it spent four attempts and up to sixty seconds apiece before reporting it unreachable. Correct behaviour against a list that had not been told, so `docs/servers.md` now has a Deliberately skipped section, with the host's row kept verbatim inside it so restoring it is one move. A host there is named as skipped in the report and costs nothing else. And the procedure said `git pull --ff-only`, which follows `master` rather than the tag being deployed. A docs commit landed mid-rollout, so every host came up on `e6f1388a` — one past `deploy/2026.08.23.01` — and "deployed the tag" was true of none of them. Harmless this time, and it need not have been: it is now fetch plus `merge --ff-only <tag>`. A host that is AHEAD of the tag is reported, never reset. Also lands the report itself, which the agent wrote and could not push. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
+20
-1
@@ -29,13 +29,32 @@ Seven, all running.
|
||||
| `alpha` | 100.64.0.1 | `pastilhas` | `~/officerdev/platform` | `officer.pastilhas.dev` |
|
||||
| `fofos` | 100.64.0.17 | `pastilhas` | `~/officerdev/platform` | `officer.fofosfluffybastards.com` |
|
||||
| `macbookpro` | 100.64.0.9 | `pastilhas` | `~/projects/officer-suite/platform` | `macbookpro.pastilhas.dev` |
|
||||
| `edge-pertento-bridge` | 100.64.0.15 | `pastilhas` | `~/officerdev/platform` | `edge.pertento.ai` |
|
||||
| `production-pertento-bridge` | 100.64.0.12 | `pastilhas` | `~/officerdev/platform` | `officer.pertento.ai` |
|
||||
| `deadpool-rezio-bridge` | 100.64.0.21 | **`br`** | `/home/br/officerdev/platform` | `officer.rezio.dev` `[pending]` |
|
||||
|
||||
Only `platform.officer.dev` is public (77.42.39.155). The rest resolve to tailnet addresses and are
|
||||
reachable from inside only.
|
||||
|
||||
## Deliberately skipped
|
||||
|
||||
A host here is NOT a deploy target. A rollout names it as skipped and moves on — it is not a failure,
|
||||
and it must not be reported as one.
|
||||
|
||||
| Host | Since | Why |
|
||||
| ---------------------- | ---------- | ---------------------------------------------------------------- |
|
||||
| `edge-pertento-bridge` | 2026-08-23 | Down, and staying down for some days. Owner's call, not a fault. |
|
||||
|
||||
Its row, kept so restoring it is one move:
|
||||
|
||||
```
|
||||
| `edge-pertento-bridge` | 100.64.0.15 | `pastilhas` | `~/officerdev/platform` | `edge.pertento.ai` |
|
||||
```
|
||||
|
||||
On 2026-08-23 the deploy agent spent four attempts and up to 60s per try on this host before reporting
|
||||
it unreachable — TCP on 22 accepted, then no SSH banner. That work was correct and entirely wasted, which
|
||||
is what this section exists to prevent: a host that is known to be down should cost a line in a report,
|
||||
not a retry budget.
|
||||
|
||||
### Names that disagree with themselves
|
||||
|
||||
Three hosts answer to more than one name, and `tailscale status` is not always the one in use:
|
||||
|
||||
Reference in New Issue
Block a user