~ knotless Search/
↑↓ move↵ open⇧↵ all results

chadtmiller.com/knotless

git that lives in your Atmosphere account

knotless.dev
1 collaborator

knotless 0.13.0 Latest 2 packages, 1 image

1
10

The iOS app shows a run's steps and logs, and runs a workflow when asked

Merged
Merged chadtmiller.com asked to merge into main from chadtmiller.com/knotless:ios/checks

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 requestRerun with 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/check and 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 recorded getCheck answer now decodes with RunDetail, and the three new requestRerun writes are held to their lexicon. just ios-look drew actions, workflow-runs, run, run-step (new screens in look.mjs) and pull-open, light and dark. look-answers.json gains a listWorkflows answer so the banner can be drawn.

Shortcomings

  • No cancel. There is no procedure for it yet, only the dev.knotless.cancel record.
  • A batch's Run again asks for its branch, not the batch.
  • The live log isn't drawn by ios-look, which has no server, so following a running check was not tried against one.
  • Run workflow takes no variables and only the default branch.
  • Pictures load from the server, so they're blank in ios-look.

🤖 Generated with Claude Code

Approved

This 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.

Merged as 8356274