Say where the whole failure is, not just the sentence about it #36
No reviewers
Labels
No labels
⏳in-progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
Grey.ooo/someones.computer_agent!36
Loading…
Reference in a new issue
No description provided.
Delete branch "feature/failure-page-url-on-a-failed-deploy"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
A failed deploy has had a page on the platform for as long as failures have been recorded: the phase that gave up, whose fault it was (
FailurePhase::remedyHint()is blunt about which side of the fence the fix is on), the build log as it stood, and a button that shares all of it for 24 hours with somebody who cannot sign in.scnever mentioned it — it printed the one sentence ofstatusReasonand stopped — so a reader had no way to know there was anywhere else to look.Both places
scshows a bad landing now name it.sc deploy, hung off the sentence it exits on:sc apps, under the row:deploykeeps thefailureframe the progress stream sends just ahead of the end frame, and returns it with the sentence as one error — so the whole answer goes to stderr with the non-zero exit, rather than half of it landing on stdout.appsprints it after the reason and independently of it: a revision can fail with nothing written against it, and the page is then the only account there is.Bumps scclient to the commit carrying
client.Failure(Grey.ooo/someones.computer_scclient#12).Verification
go test ./...green;hack/lint.sh0 issues;go vetclean.hack/coverage.sh:internal/cli85.8% against a floor of 80.7%; every other package at or above its floor.apps_test.goanddeploy_progress_test.go, including the negative case (no frame → unchanged output).The platform side that sends these fields is a separate PR on
Grey.ooo/Someones.Computer; this half degrades cleanly against a platform without it.A failed deploy has had a page on the platform for as long as failures have been recorded — the phase that gave up, whose fault it was, the build log as it stood, and a button that shares all of it for a day with somebody who cannot sign in. `sc` never mentioned it. It printed the one sentence of `statusReason` and stopped, so a reader had no way to know there was anywhere else to look, and the page went unread. Both places `sc` shows a bad landing now name it: Deployment #12 failed. kaniko exited 1 Why, in full: https://someones.computer/failures/F-24GT1BQ7 (F-24GT1BQ7) └── web ├── main failed (#1) │ Deployment #1 failed. kaniko exited 1. │ F-24GT1BQ7 — https://someones.computer/failures/F-24GT1BQ7 - `deploy` keeps the `failure` frame the progress stream sends just ahead of the end frame, and hangs it off the sentence it exits on — one error, so the whole answer lands on stderr with the non-zero exit rather than half of it on stdout. - `apps` prints it under the row, after the reason and independent of it: a revision can fail with nothing written against it, and the page is then the only account there is. A platform that sends no failure — one older than the frame, or a revision that did not land badly enough to have one — prints exactly what it printed before. Bumps scclient to the commit carrying `client.Failure`.WIP: Say where the whole failure is, not just the sentence about itto Say where the whole failure is, not just the sentence about it