Workflows
Workflows in .g1t/workflows, written as GitHub Actions and run as GitHub runs them. A run on a pull request counts as its checks.
How this runs on g1t · 26 notes
- version: `actions/checkout` checks out from g1t.
- linux: `actions/checkout` checks out from g1t.
- linux: `actions/cache/restore`: g1t keeps the cache per repository: up to 2 GiB an entry and 10 GiB a repository, until it goes 7 days unused, and at most 28 days.
- linux: `actions/cache/restore`: g1t keeps the cache per repository: up to 2 GiB an entry and 10 GiB a repository, until it goes 7 days unused, and at most 28 days.
- linux: `actions/cache/restore`: g1t keeps the cache per repository: up to 2 GiB an entry and 10 GiB a repository, until it goes 7 days unused, and at most 28 days.
- linux: `actions/upload-artifact`: g1t keeps artifacts with the run for 14 days unless the repository says otherwise, up to 5 GiB each.
- linux: `environment`: the job gets the values its secrets and variables give this environment once the environment's protection rules (required reviewers, a wait timer, which branches may deploy) let it through. Unless it says `deployment: false`, the run records a deployment to it.
- windows: `actions/checkout` checks out from g1t.
- windows: `actions/upload-artifact`: g1t keeps artifacts with the run for 14 days unless the repository says otherwise, up to 5 GiB each.
- windows: `self-hosted`: the job runs on one of the workspace's self-hosted runners that has every label in its `runs-on`, and waits until one does.
- windows: `environment`: the job gets the values its secrets and variables give this environment once the environment's protection rules (required reviewers, a wait timer, which branches may deploy) let it through. Unless it says `deployment: false`, the run records a deployment to it.
- windows_cross: `actions/checkout` checks out from g1t.
- windows_cross: `actions/cache/restore`: g1t keeps the cache per repository: up to 2 GiB an entry and 10 GiB a repository, until it goes 7 days unused, and at most 28 days.
- windows_cross: `actions/cache/restore`: g1t keeps the cache per repository: up to 2 GiB an entry and 10 GiB a repository, until it goes 7 days unused, and at most 28 days.
- windows_cross: `actions/cache/restore`: g1t keeps the cache per repository: up to 2 GiB an entry and 10 GiB a repository, until it goes 7 days unused, and at most 28 days.
- windows_cross: `actions/cache/restore`: g1t keeps the cache per repository: up to 2 GiB an entry and 10 GiB a repository, until it goes 7 days unused, and at most 28 days.
- windows_cross: `actions/upload-artifact`: g1t keeps artifacts with the run for 14 days unless the repository says otherwise, up to 5 GiB each.
- windows_cross: `environment`: the job gets the values its secrets and variables give this environment once the environment's protection rules (required reviewers, a wait timer, which branches may deploy) let it through. Unless it says `deployment: false`, the run records a deployment to it.
- macos: `actions/checkout` checks out from g1t.
- macos: `actions/upload-artifact`: g1t keeps artifacts with the run for 14 days unless the repository says otherwise, up to 5 GiB each.
- macos: `self-hosted`: the job runs on one of the workspace's self-hosted runners that has every label in its `runs-on`, and waits until one does.
- macos: `environment`: the job gets the values its secrets and variables give this environment once the environment's protection rules (required reviewers, a wait timer, which branches may deploy) let it through. Unless it says `deployment: false`, the run records a deployment to it.
- publish: `actions/checkout` checks out from g1t.
- publish: `actions/download-artifact`: g1t keeps artifacts with the run for 14 days unless the repository says otherwise, up to 5 GiB each.
- publish: `actions/cache/restore`: g1t keeps the cache per repository: up to 2 GiB an entry and 10 GiB a repository, until it goes 7 days unused, and at most 28 days.
- publish: `environment`: the job gets the values its secrets and variables give this environment once the environment's protection rules (required reviewers, a wait timer, which branches may deploy) let it through. Unless it says `deployment: false`, the run records a deployment to it.
- Merge branch 'worktree-agent-aa68cf6ecc03dffaf'#18 (attempt 2) · push by syntaqxdesktop-v0.3.71m 31s
- The desktop app no longer speaks of hosted agents. A job its runner takes says Running whatever its kind, where queue, merge check and checks tasks (which the runner's wire still calls agent work) said Agent work, and links to the repository's Actions page rather than an Agents page that no longer exists; and the app's description lists chat, artifacts and code.#17 · push by syntaqxdesktop-v0.3.615m 30s
- A computer with a sandbox the desktop app has no record of making can be put right with one button. The app said "this computer has another sandbox" and told the person to run `g1t-runner sandbox down --delete`, which looks in the default folder rather than the app's own, so it removed nothing. Most often the sandbox was the app's own from before it was uninstalled with its data deleted and installed again: deleting the app's folder left the WSL distribution behind. Now the message's button is Remove it and start again: it asks first, then removes the sandbox with its VM and registration from the app's own folder and starts a sandbox of the app's own, registered with the workspace. Uninstalling on Windows with Delete the application data ticked removes the sandbox too (an installer hook; not on an update, which keeps everything). And in the Runner window a pressed fix shows a spinner and stays pressed until the status that follows, rather than looking dead until something happens. The desktop guide says so.#16 · push by syntaqxdesktop-v0.3.513m 38s
- The desktop app is 0.3.4, and the runner has a window of its own. Beside the title bar's Settings button a chip says what the runner is doing, live, with a dot in its colour (Runner running, Running a job, Running 2 jobs, Runner starting, Runner updating, Runner stopped, Runner offline, Runner needs you), as Docker Desktop shows its engine; in a narrow window only the dot shows. It opens the Runner window, as the tray's runner row now does: at its top what the whole runner is doing, with what it is running, its version and workspace, and its own Stop or Start; then each kind of job's card as before; then its setup (running jobs here at all, how jobs run, the workspace, the computer with Check for runner updates and View on g1t); and its log, open and following along as it is written. Settings keeps the runner as one line, what it is doing with Open runner, and each window saves only its own settings over what the app has now, so neither undoes the other's. The chip's words are diagnosis.rs's, the Runner window is made off the main thread as Settings now is, and it has a capability of its own with only the commands it uses; the title bar may now ask the runner's status. Two things fixed on the way: a settings row hidden until it applies, Restart to change the title bar, showed all the time, since its row's display beat the hidden attribute; and in a narrow window the title bar's buttons ran over the search, which now shrinks instead. The desktop guide describes the chip, the Runner window and where each runner setting now is.#15 (attempt 3) · push by syntaqxdesktop-v0.3.414m 45s
- The desktop app is 0.3.3: Settings opens again on Windows, and an update found as g1t starts installs itself. Since 0.3.0, Settings opened from the title bar's button or the site's account menu showed a white window and nothing else: both are synchronous commands, which run on the main thread, and on Windows a webview window made there deadlocks (Tauri's known issue), so the window appeared and its page never loaded. The settings window is now made on a thread of its own whoever asks, and Tauri hands the making to the event loop. And so that opening g1t again is all it takes to leave a copy that misbehaves, the app looks for a newer version as it starts, three seconds after the window rather than fifteen, and one it downloads within its first two minutes is installed straight away, g1t opening again on it, before anyone has begun working in it; a runner in the middle of a job is never cut short for it, and then the update waits for Restart to update as before. After that it looks every hour rather than every six, and what it finds still waits for a restart or quitting. The desktop guide's Updates section says so.#14 · push by syntaqxdesktop-v0.3.311m 19s
- The desktop app is 0.3.2, and its runner updates are fast, seen and only ever g1t's. The app now trusts a g1t-runner release only when its manifest's Ed25519 signature, latest.json.sig, checks out against g1t's runner release key, which is built into the app (the public half of RUNNER_RELEASE_PUBLIC_KEY, kept in runner/native.rs, where development builds have it too; G1T_RUNNER_RELEASE_KEY overrides it for a g1t with its own key), as the runner already did with its own updates. A manifest with no signature, or one that doesn't check out, is refused and nothing in it is used: the runner keeps the version it has and says "Update refused: not signed by g1t", or, with no runner installed yet, "Not running: the runner's release isn't signed by g1t", each with why and what to do. It looks every hour rather than every six, on a thread of its own so the runner is looked after meanwhile, and what it finds waits, downloaded and checked, until each kind of job is idle, then goes in kind by kind, never cutting a job short: Linux jobs take the release's image (sandbox update) as soon as they have no job, while Windows jobs, whose runner is the program itself, are stopped after their job (sandbox down --only windows --drain), the program is replaced and they start again, the other kind running on throughout; a runner in Docker or on the computer stops between jobs and starts on the new one. The program there is moved aside rather than overwritten, so a status the app is asking at that moment can't stop it. Each kind of job's card in Settings shows its runner version, when the app last looked ("Checked 12 min ago") and a newer one waiting ("0.3.2 ready, installs after this job", "Installing 0.3.2"), and "Check for runner updates" beside the computer's name looks at once and installs what it finds, even with "Download updates by themselves" off, which otherwise stops the hourly look. The desktop report carries the same (snake_case: the diagnosis's update, with checked_at, ready and note, and each kind's update), so the Runners page's Desktops cards show it, "Checked" with how long ago, and this computer's row has the button too. All the words are diagnosis.rs's. The desktop guide says how updates work, what each card shows, the new troubleshooting rows and where the release key lives. Tests cover the signature with a key pair of their own and with release 0.3.0's manifest and signature as g1t.sh published them, kept byte for byte (.gitattributes), the wording, the cards and the report.#13 · push by syntaqxdesktop-v0.3.210m 19s
- The runner is 0.3.1 and the desktop app 0.3.1: each kind of job, Linux and Windows, starts and stops on its own (g1t-runner sandbox up and down --only), the settings show a card for each, and a release without the sandbox's images is waited for, not reported as a broken connection.#12 · push by syntaqxdesktop-v0.3.113m 49s
- The sandbox's VM image builds. It enabled systemd-resolved, which Debian 12 ships in a package of its own that the image did not install, so the runner release's sandbox images stopped at that step; it installs it now.#11 · push by syntaqxdesktop-v0.3.0
- Desktop release run by syntaqx#10 · manual by syntaqxmain18m 9s
- Desktop release run by syntaqx#9 · manual by syntaqxmain10m 22s
- Desktop release run by syntaqx#8 · manual by syntaqxmain12m 58s
- Desktop release run by syntaqx#7 · manual by syntaqxmain10m 37s
- Desktop release run by syntaqx#6 · manual by syntaqxmain10m 40s
- Desktop release run by syntaqx#5 · manual by syntaqxmain6m 45s
- The desktop app is 0.2.0: its own settings and menu, checking for updates with a restart beside a downloaded version, and a title bar it draws itself, in a web view of its own above the site's.#4 (attempt 3) · push by syntaqxdesktop-v0.2.06m 0s
- The desktop release's Windows job brings its own Rust when the runner's account has none, so a runner installed as a Windows service builds it without anyone touching the machine; and the runner release builds Linux and Windows only for now, since zig cannot link the macOS targets without Apple's SDK.#3 · push by syntaqxdesktop-v0.1.09m 21s
- A desktop release goes out with what can be built. Linux is built on g1t's machines in every release; Windows and macOS each wait on a repository variable: a machine registered for them, or for Windows a cross build on Linux once aka.ms and download.visualstudio.microsoft.com are workflow-only domains, which is where the first release stopped. A platform with no machine is skipped and the download page says it is coming, with a word for the visitor whose platform this release lacks. The guide and CONTRIBUTING say so.#2 (attempt 2) · push by syntaqxdesktop-v0.1.08m 1s
- Installing what Tauri needs on Linux is tried three times, in CI and in the desktop release: the mirror answered with a mismatched package once and the whole job fell with it.#1 · push by syntaqxdesktop-v0.1.09m 4s