chadtmiller.com/knotless
git that lives in your Atmosphere account
The iOS app shows a run's steps and logs, and runs a workflow when asked
MergedThis replaces the iOS app's flat runs list with a Checks page, a per-workflow runs list, a run page, a step log page and an owner-only Run workflow banner. It also makes the pull's check rows open their run.
I read all ten changed files and checked the calls against the lexicons and the server. listRuns (workflow, limit, and workflows in the answer), listCommits with subjectOnly, and the _live/check events (output, steps, going, and ended with null data) all match what the app sends and decodes. The SSE parser handles ended correctly because its data is null, not empty. The follow task doesn't loop when the stream fails or the status stays running. The new requestRerun writes and the getCheck model are covered by ios/check-models.sh, and look-answers.json has a listWorkflows answer so the banner can be drawn.
I found nothing that must change. One thing to watch: StepLogs.split expects every step's ==> name header in order. If a runner skips a step in the middle of a run without printing a header, the next step's output would be attributed to the step before it. I haven't confirmed whether runners do that, so it isn't a request.
8 passed, 2 skipped
What changes
Checks opens on the repository's workflows, each marked with how its latest run went and when, with All runs above them and the latest five runs below.
A workflow's runs (or all runs) are rows in the manner of GitHub's app: what ran (the pull, the batch or the commit's subject), the workflow and how it was set off, then chips for how long it took, when, and the branch. For the owner, a workflow they may ask for at the default branch shows a Run workflow banner, which writes
requestRerunwith that ref and workflow.A run is a page of its own: the commit's subject as its title, Status, Took and Started side by side, then the branch, the commit, its pull and its runner, each a row that opens. Then its error or why it skipped, its steps with each one's exit code and time, the last lines of a failed one under it, and the pictures it made. Its ⋯ menu runs it again, this workflow or all (owner only), copies all logs, shares or copies its link. A running one follows
/_live/checkand shows each step's output as it comes, then reads the filed run once it ends. One that is queued is read again every few seconds.A step's log opens from its row: monospaced with line numbers, colour codes taken out, scrolling sideways or wrapped. Its ⋯ menu copies or shares it, wraps lines, goes to the top or the end, and opens all logs.
A pull's check rows each open their run, with how long it took.
Why
The app stopped at a flat list of runs, with no way to see why one failed. Reading a failure is what you most want from a phone. A knotless run has steps but no jobs, so GitHub's run and job screens are one page here.
How it was checked
ios/check-models.sh: the recordedgetCheckanswer now decodes withRunDetail, and the three newrequestRerunwrites are held to their lexicon.just ios-lookdrewactions,workflow-runs,run,run-step(new screens inlook.mjs) andpull-open, light and dark.look-answers.jsongains alistWorkflowsanswer so the banner can be drawn.Shortcomings
dev.knotless.cancelrecord.ios-look, which has no server, so following a running check was not tried against one.ios-look.🤖 Generated with Claude Code