flagon-io/g1t

Commit

The desktop app's Runner settings show each kind of job as a card of its own, and each starts and stops on its own. Linux jobs and Windows jobs (macOS jobs once they are released) sit side by side, one under the other in a narrow window: an icon and name, a label for its state (Running a job, Waiting for jobs, Starting, Downloading image with how far, Updating, Waiting for image, Stopped, Not available, Problem), a line of what it is, the job it is running with a link to it, and when it isn't running why and the fix, with the fix's buttons and its own Stop or Start; its runner's name on g1t, version and isolation sit quietly below. Above the cards there is only what is about the whole runner (signed out, no workspace, turned off, stopped, the sandbox down), so nothing is said twice. Commands in the catalogue's sentences show as code, state changes are announced to screen readers, and the breathing dot stops under reduced motion.

Stopping Windows jobs leaves Linux jobs running, and the other way round. Which kinds are on is kept in the app's settings (runnerCapabilities, both on by default); every `up` names them, and stopping one is `down --only` it. g1t-runner's sandbox launcher gains that: `up --only linux,windows` turns those on and starts them, leaving the others as they are; `down --only windows` stops Windows jobs and keeps them off until `up --only windows`; `--no-native` and `--native` now mean the same as those for the OS's own kind. Its status says `turned_off` on each capability, whose state is then `stopped` with nothing in error, so a kind the person stopped reads as stopped, not failing, in the app and on the site; a Windows runner that didn't start is in `error` with why. The app never sends `down --only` to an older launcher, which would read it as `down`. A release published without the sandbox's images no longer reads as a failed download with "check the connection, or report it": Linux jobs say Waiting for the sandbox's image, "g1t-runner 0.3.0 is published without the sandbox's images yet, so Linux jobs can't start", and that g1t checks again every few minutes, with nothing for the person to do. The app looks again every five minutes in that state, by itself, while Windows jobs run on, and a kind that should run and doesn't while the other runs is started again by itself after a wait that grows to ten minutes; Retry and Check now look at once. The rest of the catalogue says what is actually wrong: an image that doesn't match the release's signature is told apart from one that didn't download, and the fixes for a failed sandbox, a stopped runner, a failed registration and a failed update say when g1t tries again and what the person can do now. The image's download says how far it is, by tenths, which the card shows as a bar. The Runners page's Desktops section shows a sandboxed desktop's kinds of job the same way, as cards in shadcn components, with a link to the run each is running and, for this computer inside the app, each kind's Stop or Start. Desktop reports carry each kind's state, whether it was stopped, its job, runner, isolation and version, and whether the cards say it all (`in_capabilities`), all snake_case. The desktop and self-hosted runner guides say all of it, the troubleshooting table each state's words.