apps · flagon-io/g1t

apiA workflow that deploys to AWS, Google Cloud or Azure with the job's OIDC token now says how to reach the cloud's token service, and the docs say where to look when a job has no token. The issuer, its keys and the token endpoint were already live at https://api.g1t.sh/actions/oidc, and a job with `permissions: id-token: write` already got ACTIONS_ID_TOKEN_REQUEST_URL and ACTIONS_ID_TOKEN_REQUEST_TOKEN. But on g1t's machines a job reaches only the hosts its project allows, and no cloud's token exchange is among them, so a login step following the docs failed with a bare 403. The OIDC section of the Actions guide has a new part, Reaching your cloud. It lists the hosts each cloud's login needs (sts.<region>.amazonaws.com; sts.googleapis.com and iamcredentials.googleapis.com; login.microsoftonline.com and management.azure.com) and says to add them as workflow-only domains limited to the deploying workflow and environment. Each cloud's steps now include that step, and the guide says what a job without `id-token: write` sees. The secrets section of the Actions guide, Secrets and variables, and the guardrails page's workflow-only domains each point to OIDC tokens as the way to deploy without keeping a cloud key.2d ago

desktopThe 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.2d ago

docsA workflow that deploys to AWS, Google Cloud or Azure with the job's OIDC token now says how to reach the cloud's token service, and the docs say where to look when a job has no token. The issuer, its keys and the token endpoint were already live at https://api.g1t.sh/actions/oidc, and a job with `permissions: id-token: write` already got ACTIONS_ID_TOKEN_REQUEST_URL and ACTIONS_ID_TOKEN_REQUEST_TOKEN. But on g1t's machines a job reaches only the hosts its project allows, and no cloud's token exchange is among them, so a login step following the docs failed with a bare 403. The OIDC section of the Actions guide has a new part, Reaching your cloud. It lists the hosts each cloud's login needs (sts.<region>.amazonaws.com; sts.googleapis.com and iamcredentials.googleapis.com; login.microsoftonline.com and management.azure.com) and says to add them as workflow-only domains limited to the deploying workflow and environment. Each cloud's steps now include that step, and the guide says what a job without `id-token: write` sees. The secrets section of the Actions guide, Secrets and variables, and the guardrails page's workflow-only domains each point to OIDC tokens as the way to deploy without keeping a cloud key.2d ago

mobileEAS builds of the phone app skip expo doctor. Its one failing check is the second React (the app's 19.2.3 beside the site's 19.3.0 at the root), which metro.config.js already resolves to one copy; the doctor cannot allow a single duplicate, and React Native 0.86 needs 19.2.3 while the site needs 19.2.8 or newer. npm run doctor still runs it.2d ago

statusdocs.g1t.sh and status.g1t.sh follow your system's light or dark setting, and each has an Auto, Light and Dark switch that this browser remembers: the docs' in the header (at the foot of the menu on a phone), with code, search, the API reference and its explorer in both themes; the status page's in its header, chosen before anything is drawn; the workspaces guide says where.4d ago

sudoThe docs folder is gone, and what it held lives where people read it: how a self-hosted g1t runs and how to deploy g1t to Cloudflare are pages on docs.g1t.sh under Run g1t yourself, and speed, rate limits and operating g1t.sh are sections of CONTRIBUTING.md; code that cited a file in docs/ now points to the page or section that covers it, or says what it means itself, and applied migrations and the runner images are left as they were.4d ago

webThe 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.2d ago