Say why a deployment failed, under the row that says it failed #29

Merged

geusebio merged 3 commits from feature/show-why-a-deployment-failed into main

2026-08-17 08:19:39 +00:00

geusebio commented

2026-08-16 20:31:41 +00:00

Owner

The sc half of Someones.Computer#791 — a failed revision's reason was written to a stream nobody was still attached to.

BLOCKED, and knowingly red

This cannot go green until scclient#8 merges. agent/ vendors scclient, so client.Deployment here has no StatusReason field until go.mod is bumped to a pseudo-version containing that commit and go mod vendor is re-run. The lint job fails exactly there:

internal/cli/apps.go:207:39: deployment.StatusReason undefined (typecheck)

That bump is deliberately not in this PR: pinning go.mod at an unmerged branch commit is how a pin ends up sitting on a commit that never lands. Sequence is scclient#8 → bump + re-vendor here → un-draft.

What it does

sc apps drew a failed revision as main failed (#1) and stopped, so the obvious next question went unanswered — and every other route out was a dead end too: sc logs said nothing was running, sc deploy refused to retry. The reason now hangs under the row it explains:

acme  (owner)
└── web
    ├── main  failed (#1)
    │   Deployment #1 failed. This revision publishes a port, but no runtime
    │   context available to it can route one: the last attempt to install
    │   the edge failed. Nothing in the revision needs changing and
    │   redeploying will not help — an operator has to install the platform
    │   edge (app:ingress:install) on the context first.
    └── staging  running (#2)

Indented to line up with the row's text, not with the branch character, so the tree still reads as a tree.
Only when there is one. Nearly every revision has nothing to explain and gains no lines at all — not even a blank one. Whitespace is not a reason.
Wrapped at 72 on spaces, never mid-word. A word longer than the width (a URL, a command name) takes its own line rather than being cut — a broken URL is worse than a long line.

Verification

go build ./..., go vet ./..., go test ./... clean with the workspace (go.work resolves scclient by path, which is how the platform repo makes a contract change on every side at once). The vendored build is what fails, per above.
New tests: the printed tree with a reason in it, that a reason-less revision adds no lines, and the wrap's three behaviours (break on spaces, keep an over-long word intact, nothing from nothing).
Coverage ratchet holds and rose: internal/cli 81.7% against a floor of 80.7%. coverage.floor deliberately not bumped — the recorded figures are Linux numbers and this run is macOS, which hack/coverage.sh calls out as the way a bump from a laptop turns a runner red.

The `sc` half of [Someones.Computer#791](https://git.grey.ooo/Grey.ooo/Someones.Computer/issues/791) — a failed revision's reason was written to a stream nobody was still attached to. ## BLOCKED, and knowingly red **This cannot go green until [scclient#8](https://git.grey.ooo/Grey.ooo/someones.computer_scclient/pulls/8) merges.** `agent/` vendors `scclient`, so `client.Deployment` here has no `StatusReason` field until `go.mod` is bumped to a pseudo-version containing that commit and `go mod vendor` is re-run. The lint job fails exactly there: ```text internal/cli/apps.go:207:39: deployment.StatusReason undefined (typecheck) ``` That bump is deliberately **not** in this PR: pinning `go.mod` at an unmerged branch commit is how a pin ends up sitting on a commit that never lands. Sequence is scclient#8 → bump + re-vendor here → un-draft. ## What it does `sc apps` drew a failed revision as `main failed (#1)` and stopped, so the obvious next question went unanswered — and every other route out was a dead end too: `sc logs` said nothing was running, `sc deploy` refused to retry. The reason now hangs under the row it explains: ```text acme (owner) └── web ├── main failed (#1) │ Deployment #1 failed. This revision publishes a port, but no runtime │ context available to it can route one: the last attempt to install │ the edge failed. Nothing in the revision needs changing and │ redeploying will not help — an operator has to install the platform │ edge (app:ingress:install) on the context first. └── staging running (#2) ``` - **Indented to line up with the row's text**, not with the branch character, so the tree still reads as a tree. - **Only when there is one.** Nearly every revision has nothing to explain and gains no lines at all — not even a blank one. Whitespace is not a reason. - **Wrapped at 72 on spaces, never mid-word.** A word longer than the width (a URL, a command name) takes its own line rather than being cut — a broken URL is worse than a long line. ## Verification - `go build ./...`, `go vet ./...`, `go test ./...` clean **with the workspace** (`go.work` resolves `scclient` by path, which is how the platform repo makes a contract change on every side at once). The vendored build is what fails, per above. - New tests: the printed tree with a reason in it, that a reason-less revision adds no lines, and the wrap's three behaviours (break on spaces, keep an over-long word intact, nothing from nothing). - Coverage ratchet holds and rose: `internal/cli` 81.7% against a floor of 80.7%. `coverage.floor` deliberately **not** bumped — the recorded figures are Linux numbers and this run is macOS, which `hack/coverage.sh` calls out as the way a bump from a laptop turns a runner red.

geusebio added 1 commit

2026-08-16 20:31:42 +00:00

Say why a deployment failed, under the row that says it failed

CI / build (pull_request) Failing after 19s

Details

1414c0b4e3

`sc apps` drew a failed revision as `main  failed (#1)` and stopped there, so
the one question a person has on seeing it went unanswered. The platform has
the answer and it is a good one — often including that redeploying will not
help — but it was reachable only by being attached to the deploy's progress
stream at the instant the revision terminated.

The reason now hangs under the row it explains, wrapped and indented to line up
with the row's text so the tree still reads as a tree. Printed only when there
is one, which is nearly never: a revision with nothing to explain gains no
lines at all.

Wrapping breaks on spaces and never mid-word; a word longer than the width —
a URL, a command name — takes a line of its own rather than being cut.

geusebio added 1 commit

2026-08-16 23:59:04 +00:00

Merge remote-tracking branch 'origin/main' into feature/show-why-a-deployment-failed

CI / build (pull_request) Failing after 57s

Details

b2b612cfab

geusebio referenced this pull request from a commit

2026-08-17 07:48:24 +00:00

Make a failed revision's reason reachable after the fact (#814)

geusebio added 1 commit

2026-08-17 08:00:59 +00:00

Bump scclient to the release carrying StatusReason

CI / build (pull_request) Successful in 6m49s

Details

1bb68d1df1

`sc apps` reads a field this module vendors, so the pin has to move before it
compiles. scclient main now carries the managed-service verbs as well, so this
is one forward move that drops nothing.

geusebio changed title from ~~WIP: Say why a deployment failed, under the row that says it failed~~ to Say why a deployment failed, under the row that says it failed

2026-08-17 08:13:42 +00:00

geusebio merged commit 8605e1795e into main

2026-08-17 08:19:39 +00:00

geusebio deleted branch feature/show-why-a-deployment-failed

2026-08-17 08:19:39 +00:00

geusebio referenced this pull request from a commit

2026-08-17 08:19:41 +00:00

Say why a deployment failed, under the row that says it failed (#29)