flagon-io/g1t

public

Where people and agents ship software together. The open-source git platform for the whole job: issues, agents, checks and deploys to the edge.

g1t.sh

git agents cloudflare rust forge mcp

1,803 linesCode BlameRaw

1	---
2	title: GitHub Actions
3	description: Your GitHub Actions workflows run on g1t as they are. Rename .github to .g1t and push.
4	---
5
6	g1t runs GitHub Actions workflows. They are written exactly as on GitHub,
7	and kept in `.g1t/workflows/` instead of `.github/workflows/`.
8
9	## Moving from GitHub
10
11	```sh
12	git mv .github .g1t
13	git commit -m "Run our workflows on g1t"
14	git push g1t main
15	```
16
17	That is the whole move. Everything in the folder comes along: workflows,
18	local actions under `.g1t/actions/` and anything else you keep there.
19	Workflows that still say `uses: ./.github/actions/setup` find it under
20	`.g1t/` once `.github` is gone.
21
22	Otherwise g1t doesn't read `.github`, so a repository that lives in both
23	places can keep `.github` for GitHub and `.g1t` for g1t, side by side.
24
25	### On a mirror
26
27	A [mirror](/guides/mirroring/) of a GitHub repository runs nothing while it
28	stands by: its workflows run on GitHub. Its owners can change that:
29
30	- CI failover runs its workflows on g1t for each push copied in from
31	GitHub, `.github/workflows` as well as `.g1t/workflows`. Use it when
32	GitHub's workflows aren't running.
33	- Taking over runs them for everything pushed to g1t, until it's handed
34	back.
35	- Keep CI warm runs `.g1t/workflows`, and only those, on each push
36	copied in while it stands by.
37
38	When both folders have a workflow of the same `name:`, the one in `.g1t`
39	runs. A workflow that deploys (any job names an `environment:`) waits for
40	approval during CI failover and takeovers, so it doesn't deploy from two
41	places, unless the mirror's settings say otherwise. A push copied in from
42	GitHub that changes workflows or local actions waits for approval before
43	it can use the repository's secrets.
44
45	Whenever g1t runs a mirror's workflows, their results show on the commit on
46	GitHub too, as commit statuses named `g1t / <workflow> / <event>`, such as
47	`g1t / CI / push`. This needs the Commit statuses permission on g1t's GitHub
48	App; turn it off with Report checks to GitHub in the mirror's settings.
49	See [Checks on GitHub](/guides/mirroring/#checks-on-github).
50
51	Then add your [secrets and variables](#secrets-and-variables): GitHub never
52	gives their values out, so they cannot be copied across.
53
54	## What runs
55
56	\| On GitHub \| On g1t \|
57	\| --- \| --- \|
58	\| `on:` `push` (branches, tags, paths), `pull_request`, `pull_request_target`, `issues`, `issue_comment`, `pull_request_review`, `schedule`, `workflow_dispatch`, `workflow_run`, `merge_group`, `create`, `delete`, `repository_dispatch`, `release`, `deployment`, `deployment_status` \| The same, from g1t's own pushes, pull requests, issues, comments, [releases](#releases), [deployments](#deployments) and [merge queue](/guides/merge-queue/). `create` starts on each new branch or tag, at its commit; `delete` on each branch or tag a push deletes, on the default branch's latest commit, with `github.event.ref` and `github.event.ref_type` naming what went. As on GitHub, neither takes `branches` or `tags` filters: a workflow on them runs for every branch and tag. `repository_dispatch` starts on [a dispatch event](#repository-dispatch). \|
59	\| `jobs`, `needs`, `if`, `outputs`, `env`, `defaults`, `timeout-minutes`, `continue-on-error` \| The same. \|
60	\| `timeout-minutes` and `continue-on-error` on a step \| The same, for `run:` and `uses:` steps alike. A `uses:` step's action is stopped at its limit, with every process it started; a step inside a composite action stops at its own limit or the `uses:` step's, whichever comes first. A step stopped this way fails, unless `continue-on-error` lets the job go on. \|
61	\| `strategy.matrix` with `include` and `exclude`, `fail-fast`, `max-parallel`, a matrix from `fromJSON(needs.…)` \| The same. \|
62	\| `concurrency` with `cancel-in-progress`, for the workflow or for one job \| The same: one run, or one job, of a group at a time. \|
63	\| `permissions:` for the workflow or for one job, `read-all`, `write-all` \| The same: they decide what [the job's token](#the-jobs-token) may do. \|
64	\| `${{ }}` expressions: every operator, function and context \| The same, including `hashFiles`, `success()`, `failure()`, `always()` and `cancelled()`. \|
65	\| `run:` with `bash`, `sh`, `python`, `pwsh` or a custom shell \| The same, with GitHub's file for each: `.sh` for `bash` and `sh`, `.py` for `python`, `.ps1` for PowerShell (stopping at the first error, and exiting with the last program's code), `.cmd` for `cmd`, and no extension for another program. `python` runs `python`, or `python3` on a machine without it. \|
66	\| JavaScript actions (`uses: owner/repo@v7`, `owner/repo/path@v7`) \| Fetched from that repository on g1t when g1t has it and your repository may use it, otherwise from GitHub, and run as they are, on Node 24, the runtime current actions declare. An action that declares `node20` runs on Node 20 where the machine has one. See [actions and workflows from other repositories](#actions-and-workflows-from-other-repositories) and [an action's pre and post](#an-actions-pre-and-post). \|
67	\| Composite actions \| The same. \|
68	\| Reusable workflows (`jobs.<id>.uses: ./.g1t/workflows/build.yml`, or `owner/repo/.g1t/workflows/build.yml@v1` in another repository) \| The same: `with:` inputs checked against their `type`, `secrets:` by name or `secrets: inherit`, `on.workflow_call` outputs, `strategy.matrix` on the calling job (one call for each combination), `concurrency` on the calling job, and up to ten levels of workflows with at most 50 different reusable workflows in a run. `.github/workflows/…` finds the workflow under `.g1t/` after the move. See [actions and workflows from other repositories](#actions-and-workflows-from-other-repositories). \|
69	\| `actions/checkout` \| Checks out from g1t, with `ref`, `fetch-depth`, `path`, `repository`, `token` and `submodules`. \|
70	\| `GITHUB_OUTPUT`, `GITHUB_ENV`, `GITHUB_PATH`, `GITHUB_STATE`, `GITHUB_STEP_SUMMARY` \| The same. Step summaries show on the run's page; see [job summaries](#job-summaries). \|
71	\| `::error::`, `::warning::`, `::notice::`, `::group::`, `::add-mask::`, `::echo::on` \| The same: errors and warnings become annotations on the run, with their `file`, `line`, `col`, `endLine` and `endColumn`, and [masked](#masking-secrets) values stay hidden. \|
72	\| Problem matchers (`::add-matcher::`, `::remove-matcher::`) \| The same, so `actions/setup-node`, `setup-go` and `setup-python` turn compiler and linter output into annotations. See [problem matchers](#problem-matchers). \|
73	\| `secrets.`, `vars.`, `secrets.GITHUB_TOKEN` \| The same. `secrets.G1T_TOKEN` is [the job's own token](#the-jobs-token); `GITHUB_TOKEN` is its alias. \|
74	\| `environment:` on a job \| The job waits for the environment's [protection rules](#environments), then reads each key's row for that environment, as environment secrets work, and the run records a [deployment](/guides/deployments-api/#deployments-from-g1t-actions) to it. `url` gives the deployment its address; `deployment: false` reads the environment's values without making one. The name may be an expression. \|
75	\| `actions/upload-artifact`, `actions/download-artifact`, `actions/upload-artifact/merge` \| The same inputs and outputs as version 4: `retention-days`, `overwrite`, `compression-level`, `include-hidden-files`, `!` exclusions, download by `pattern` with `merge-multiple`, and from another run with `run-id` and `github-token`. Up to 5 GiB each; see [artifacts](#artifacts). \|
76	\| `actions/cache`, `actions/cache/restore`, `actions/cache/save` \| The actions themselves, at the version the step names, saving to and restoring from the repository's cache: kept per repository and branch, found by `key` or the newest under a `restore-keys` prefix. Up to 2 GiB each; see [the cache](#the-cache). \|
77	\| Actions that cache through the toolkit, such as `actions/setup-node` with `cache: npm` or `Swatinem/rust-cache` \| The same: they save to and restore from the repository's cache. See [actions built on the toolkit](#actions-built-on-the-toolkit). \|
78	\| sccache with `SCCACHE_GHA_ENABLED` \| The same: its entries go to the repository's cache. See [caching Rust builds](#caching-rust-builds). \|
79	\| `permissions: id-token: write` \| The job can ask for an OIDC token, and trade it for a cloud provider's credentials. See [OIDC tokens](#oidc-tokens). \|
80	\| `docker build`, `push`, `run`, `login`, `compose`, Buildx \| The same, with a Docker Engine of the job's own. See [Docker](#docker). \|
81	\| `services:` \| The same: each service starts before the steps, health checks are waited for, and it is reached at `localhost` on its port and by its name. \|
82	\| `container:` \| The same: every step runs inside the image. \|
83	\| `uses: docker://image`, Docker actions (`runs.using: docker`) \| The same: built from the action's Dockerfile or pulled, and run with GitHub's `/github/workspace` layout. \|
84	\| `docker/setup-buildx-action`, `docker/build-push-action`, `docker/login-action` \| The same. `setup-buildx-action` picks the job's own Engine as the builder. \|
85
86	The Actions page of a workflow says, under How this runs on g1t,
87	anything in it that runs differently.
88
89	### Not yet
90
91	- Windows and macOS on g1t's machines. g1t's own runners are Linux; a
92	job with `runs-on: windows-latest` or `macos-latest` fails, and says so.
93	[Self-hosted runners](/guides/self-hosted-runners/) of any OS run them:
94	`runs-on: [self-hosted, windows]`.
95	- Docker's `type=gha` build cache. Buildx skips it on g1t, and the
96	build runs without a cache. Use a registry cache instead; see
97	[caching image builds](#caching-image-builds).
98	- **Actions that upload artifacts with the toolkit's artifact library
99	themselves.** The library refuses to run against any server but
100	github.com. `actions/upload-artifact`, `actions/download-artifact` and
101	`actions/upload-artifact/merge` work, because g1t runs them itself. See
102	[actions built on the toolkit](#actions-built-on-the-toolkit).
103	- `on: label`, and some activity types. Creating, editing or deleting
104	a label starts no workflows yet, and the workflow's page says so. Nor do
105	the `pull_request` types `unassigned`, `locked` and `unlocked`, `edited`
106	for a new title or description, or the `issues` types `unassigned`,
107	`locked`, `unlocked`, `pinned` and `unpinned`.
108	- Background steps. A step with `background: true`, or a `wait`,
109	`wait-all`, `cancel` or `parallel` step, is refused: g1t does not run
110	them yet.
111	- **`timezone` on a schedule, `concurrency.queue`, `cancel-timeout-minutes`
112	and `snapshot`.** The workflow runs without them, and its page says so:
113	a schedule runs in UTC, a group keeps one run waiting, a cancelled job
114	stops in its usual time, and no runner image is made.
115
116	Why each of these is missing, and what to use instead, is on
117	[What g1t can't do yet](/about/limitations/#actions-and-runners).
118
119	## Skipping a run
120
121	A commit can ask not to start the `push` and `pull_request` workflows it
122	would, as on GitHub: put `[skip ci]`, `[ci skip]`, `[no ci]`,
123	`[skip actions]` or `[actions skip]` anywhere in its message, or end the
124	message with a `skip-checks: true` trailer. For a push, the message read
125	is the pushed head's; for a pull request, its head commit's. Other
126	events, such as `pull_request_target`, `workflow_dispatch` and
127	`schedule`, still start their workflows.
128
129	```sh
130	git commit -m "Fix a typo in the README [skip ci]"
131	```
132
133	A required check that a skipped workflow would have reported stays
134	pending, so a pull request whose merge needs it waits for a push that
135	runs it.
136
137	## How g1t checks a workflow
138
139	g1t reads a workflow as GitHub does, from GitHub's own schema for workflow
140	files, so a workflow GitHub refuses is refused on g1t too, and one GitHub
141	runs reads on g1t. When a workflow can't be read, its page says what is
142	wrong, with the job and step, and no run starts from it.
143
144	\| You write \| g1t says \|
145	\| --- \| --- \|
146	\| A key GitHub doesn't have, at any level, such as `runs_on:` or `with:` on a `run:` step \| It is unexpected, and lists the keys that place can have. \|
147	\| A job without `runs-on` \| The job has no `runs-on`. A job that calls a reusable workflow with `uses:` has no `runs-on` or `steps`. \|
148	\| A job id that doesn't start with a letter or `_`, has characters other than letters, digits, `-` and `_`, or starts with `__` \| It is not a job id GitHub accepts. Step ids follow the same rule. Two jobs, or two steps of a job, whose ids differ only in case are the same id. \|
149	\| An event GitHub doesn't have, or a filter the event doesn't take, such as `types` on `push` \| GitHub has no such event, or the event doesn't take that key. `branches` and `branches-ignore` (and `tags`, `paths`) can't both be on one event. \|
150	\| A YAML merge key (`<<: defaults`) \| GitHub doesn't read merge keys. Anchors and aliases (`&steps` and `steps`) work, as on GitHub, for a whole value. \|
151	\| A `permissions` name GitHub's token doesn't have, such as `metadata` \| It is unexpected. A name GitHub has that g1t has nothing behind yet reads, and grants nothing. \|
152
153	### g1t's own settings
154
155	A `g1t:` mapping can go at the top of a workflow, on a job and on a step.
156	GitHub refuses a workflow with `g1t:` in it, so use it only in
157	`.g1t/workflows`. It follows two rules:
158
159	- It only adds to a workflow. It never changes what a GitHub key means.
160	- Each setting in it has a GitHub equivalent, written here, so that a
161	workflow can be moved back to GitHub without it.
162
163	\| Setting \| Where \| What it does \| On GitHub \|
164	\| --- \| --- \| --- \| --- \|
165	\| `deployment: false` \| A job \| The job reads its `environment:` values without the run recording a deployment. \| `environment: { name: ..., deployment: false }` \|
166
167	g1t keeps any other key under `g1t:` as written, and does nothing with it
168	yet.
169
170	## Managed workflows
171
172	Some workflows run in a repository without a file in it: g1t installs
173	them for a feature you turn on, such as a project's
174	[build with a workflow](/guides/deployments/#build-with-a-workflow). A
175	managed workflow runs like any other: on the Actions page, with its
176	runs, logs, re-runs and checks, on g1t's machines or your
177	[self-hosted runners](/guides/self-hosted-runners/). Its page says it is
178	managed by g1t.
179
180	A workflow of the same `name:` in `.g1t/workflows/` runs in its place, so
181	to change one, commit your own version of it.
182
183	## Schedules
184
185	A workflow with `on: schedule` runs on the default branch's latest commit,
186	at each time its cron lines name, in UTC:
187
188	```yaml
189	on:
190	schedule:
191	- cron: "0 9 * * mon" # Mondays at 09:00 UTC
192	- cron: "/30 * * *" # every 30 minutes
193	```
194
195	Each line has five fields: minute, hour, day of month, month and day of
196	the week. A field takes `*`, a number, a range `1-5`, a list `1,15` and a
197	step `*/10`; days take `mon` to `sun`, and months `jan` to `dec`.
198
199	\| Rule \| What happens \|
200	\| --- \| --- \|
201	\| Every 5 minutes at most \| A schedule more frequent than every 5 minutes, such as `* * * * ` or `/2 * * * `, runs every 5 minutes instead, on the five-minute marks (:00, :05, :10 and so on), at each mark that ends five minutes in which it would have run. A mark outside the hours, days or months the schedule names never runs: ` 9 * * *` runs from 09:00 to 09:55. \|
202	\| No push for 60 days \| Schedules pause in a repository that has had no push for 60 days. The next push to any branch resumes them. Other events and `workflow_dispatch` still start the workflow. \|
203	\| Actions not paid for \| When a scheduled run's job could not start because the workspace's plan, spend limit or the open-source pool does not cover it, that run fails and says why, and the workflow's schedule waits an hour before it tries again. \|
204	\| Archived repository \| Schedules wait until the repository is unarchived. \|
205
206	## Actions and workflows from other repositories
207
208	A step's `uses: owner/repo@ref` (or `owner/repo/path@ref`) and a job's
209	`uses: owner/repo/.g1t/workflows/build.yml@ref` name another repository.
210	g1t looks for it on g1t first, but a name means what it means on GitHub
211	whenever GitHub has it:
212
213	\| The repository \| What happens \|
214	\| --- \| --- \|
215	\| On g1t and public: in your workspace, under `g1t/`, or with a name GitHub has no public repository of \| Your workflows use it, from any workspace. \|
216	\| On g1t, private, in your workspace, with Access set to Accessible from repositories in the workspace \| Your private repositories' workflows use it. A job reads it with a read-only token for that repository alone, which ends with the job. \|
217	\| On g1t, private, and not shared that way \| The step or job fails, and says why. A private repository's actions are never used by a public repository's workflows, whose logs anyone can read, nor from another workspace. \|
218	\| Not on g1t, or private in a workspace you cannot see \| An action comes from GitHub, at the commit its ref names there (see [actions from GitHub](#actions-from-github)); a reusable workflow is read from a public repository on GitHub. \|
219	\| On g1t, public, in another workspace, with a name GitHub has a public repository of \| GitHub's is used, as on GitHub: anyone can make a workspace, so a workspace called `actions` never answers for `actions/setup-node`. When g1t can't reach GitHub to tell, GitHub's is used too. \|
220
221	`ref` is a branch, a tag or a commit. A reusable workflow may be under
222	`.g1t/workflows/` or `.github/workflows/`; a `.github/workflows/` path
223	also finds the file under `.g1t/workflows/` in a repository moved to
224	g1t. A `./.g1t/workflows/…` call inside a workflow from another
225	repository reads from that repository, at the same ref.
226
227	To share a private repository's actions and workflows with the rest of its
228	workspace, an admin chooses **Settings → Actions → Access → Accessible from
229	repositories in** the workspace, or calls
230	`PUT /repos/{owner}/{repo}/actions/permissions/access` with
231	`{"access_level": "organization"}` (`none` to stop).
232
233	### Actions from GitHub
234
235	g1t keeps the actions your workflows use from GitHub, so a job downloads
236	them from g1t rather than from GitHub:
237
238	1. Before the first step, the job downloads every action its steps name,
239	as GitHub's runner does in Set up job, and fails there if one can't
240	be had. Its log names each one's commit:
241	`Download action repository 'actions/setup-node@v4' (SHA:…) from g1t`.
242	2. g1t reads which commit the ref (`v4`, a branch, or a commit) names on
243	GitHub, a tag before a branch of the same name, and looks again at
244	most every 5 minutes, so a tag that moves is followed within minutes.
245	3. The first job to use an action at a commit has g1t fetch that commit's
246	archive from GitHub and keep it. Every later job, in any workspace,
247	downloads the same bytes from g1t.
248
249	While GitHub doesn't answer, a ref reads as the commit it last named, and
250	the job says so in a warning; an action g1t keeps still downloads. An
251	action whose archive is larger than 32 MB, or from a private repository
252	on GitHub, is downloaded from GitHub by the job itself. An archive no job
253	has used for 30 days is deleted, and fetched again when next used.
254	Kept archives are g1t's and count toward no workspace's storage.
255
256	Actions that a composite action uses are downloaded when it runs.
257
258	### g1t's own actions
259
260	The `g1t` workspace on g1t.sh holds g1t's own actions, public, with a
261	`v1` tag that moves with each compatible release:
262
263	\| Action \| What it does \|
264	\| --- \| --- \|
265	\| [`g1t/deploy@v1`](https://g1t.sh/g1t/deploy) \| Builds the checkout and puts it on [g1t.page](/guides/deployments/): production from the project's production branch, a preview from a pull request or another branch. The job needs `deployments: write`. See [deploying from a workflow](/guides/deployments/#deploying-from-a-workflow). \|
266	\| [`g1t/detect@v1`](https://g1t.sh/g1t/detect) \| Says what that build would find (`kind`, `install`, `build`, `output-dir`) without building anything. \|
267
268	Both are composite actions around `g1t-runner`, which g1t's machines
269	have; on a [self-hosted runner](/guides/self-hosted-runners/) they use
270	the one on `PATH` or download the newest release.
271
272	### Secrets for a called workflow
273
274	A called workflow gets only the secrets its caller passes, plus
275	`G1T_TOKEN` (`GITHUB_TOKEN`):
276
277	```yaml
278	jobs:
279	build:
280	uses: acme/shared/.g1t/workflows/build.yml@v2
281	with:
282	node-version: 24
283	secrets:
284	npm-token: ${{ secrets.NPM_TOKEN }}
285
286	deploy:
287	uses: ./.g1t/workflows/deploy.yml
288	secrets: inherit
289	```
290
291	- `secrets:` with names passes each as the called workflow names it,
292	read from the caller's `secrets`, `needs`, `inputs`, `matrix`,
293	`github` and `vars`.
294	- `secrets: inherit` passes every secret the caller has.
295	- A job in the called workflow with its own `environment:` also reads that
296	environment's secrets, over what was passed.
297	- A secret the called workflow marks `required: true` under
298	`on.workflow_call.secrets` that the caller does not pass fails the
299	calling job before anything runs.
300
301	`vars` are the calling repository's, and a called workflow's jobs run
302	with the calling run's `github` context: `actions/checkout` checks out the
303	calling repository.
304
305	A secret passed by name that the called workflow does not declare under
306	`on.workflow_call.secrets` fails the calling job: `Invalid secret: … is
307	not defined in …`.
308
309	### Inputs for a called workflow
310
311	The values under `with:` are checked against the `type` each input has
312	under `on.workflow_call.inputs`, before anything runs:
313
314	- A `boolean` input takes `true` or `false`, and a `number` input a
315	number. Text such as `'true'` or a job's output (outputs are always
316	text) fails the calling job: pass `${{ fromJSON(needs.build.outputs.count) }}`
317	to give its value.
318	- A `string` input takes text; a number or a boolean becomes its text.
319	- An input you leave out takes its `default`, else `false`, `0` or `''`
320	by its type. A `required: true` input you leave out fails the calling
321	job.
322	- A name under `with:` that the called workflow does not declare fails the
323	calling job: `Invalid input: … is not defined in …`.
324
325	### A matrix of calls
326
327	A job that calls a reusable workflow may have a `strategy`. Each
328	combination of its matrix calls the workflow once, with `matrix` read in
329	`with:` and `secrets:`:
330
331	```yaml
332	jobs:
333	test:
334	strategy:
335	matrix:
336	node: [20, 22]
337	max-parallel: 1
338	uses: ./.g1t/workflows/test.yml
339	with:
340	node-version: ${{ matrix.node }}
341	```
342
343	The called workflow's jobs are named under the combination's call:
344	`test (20) / unit`, `test (22) / unit`. `max-parallel` limits how many
345	calls run at a time, and with `fail-fast` (the default) a call that fails
346	cancels the calls still running or waiting. `concurrency` on the calling
347	job holds its group while the called workflow runs, as a job's own does.
348
349	A run connects at most ten levels of workflows: the workflow it started
350	from and nine levels of reusable workflows below it. It calls at most 50
351	different reusable workflows; a workflow called again, as by each
352	combination of a matrix, counts once. A call past either limit fails the
353	calling job and says why.
354
355	## Releases
356
357	Workflows with `on: release` start when a release changes, at the commit
358	its tag names (`GITHUB_REF` is `refs/tags/<tag>`). Each change is one or
359	more activity types, which `types:` chooses among:
360
361	\| Change \| Activity types \|
362	\| --- \| --- \|
363	\| A draft made \| `created` \|
364	\| A release made and published \| `created`, `published`, and `released` (or `prereleased` for a prerelease) \|
365	\| A draft published \| `published`, and `released` or `prereleased` \|
366	\| A prerelease made a full release \| `edited` and `released` \|
367	\| Made a draft again \| `unpublished` \|
368	\| Title, notes or prerelease changed \| `edited`, with `github.event.changes` holding the old title and notes \|
369	\| Deleted (the tag stays) \| `deleted` \|
370
371	```yaml
372	on:
373	release:
374	types: [published]
375	```
376
377	`github.event.release` has `tag_name`, `name`, `body`, `draft`,
378	`prerelease`, `target_commitish`, `author` and `html_url`. A release a
379	job's own token makes or changes starts no workflows.
380
381	## Deployments
382
383	`on: deployment` starts when a deployment is made, and
384	`on: deployment_status` when one has a new status: one reported through
385	the [deployments API](/guides/deployments-api/) or a
386	[g1t.page](/guides/deployments/) build. The run is at the commit deployed;
387	`GITHUB_REF` is the branch or tag deployed, and empty for a bare commit.
388
389	```yaml
390	on: deployment_status
391
392	jobs:
393	smoke:
394	if: github.event.deployment_status.state == 'success'
395	runs-on: ubuntu-latest
396	steps:
397	- run: curl -fsS "${{ github.event.deployment_status.environment_url }}"
398	```
399
400	`github.event.deployment` has `environment`, `ref`, `sha`, `task` and
401	`payload`; `github.event.deployment_status` has `state`, `environment_url`
402	and `log_url`. Deployments a workflow makes, with `environment:` or with
403	its job's token, start no workflows, so a workflow cannot set itself off.
404
405	## The runner
406
407	Jobs run in a fresh sandbox each: Debian with Node 24, Python 3, Go, Rust,
408	Java 21, .NET 8, Ruby 3.3, `build-essential`, `git`, `curl`, `jq`, Docker
409	(with Buildx and Compose) and passwordless `sudo`, in GitHub's layout
410	(`/home/runner/work`, `RUNNER_WORKSPACE`, `RUNNER_TEMP`, `RUNNER_TOOL_CACHE`).
411	`runner.os` is `Linux`. Each step's `GITHUB_ACTION` is its `id`, or
412	GitHub's name for it: `__run`, `__run_2` and on for `run:` steps,
413	`__actions_checkout` for `uses: actions/checkout`. `ImageOS` and
414	`ImageVersion` are set when the machine's image sets them. `ubuntu-latest`, `ubuntu-24.04` and other Linux
415	labels all run here. A job whose `runs-on` names `self-hosted` waits for one
416	of your [self-hosted runners](/guides/self-hosted-runners/) instead. Setup actions such as
417	`actions/setup-node` and `actions/setup-python` install other versions as
418	they do on GitHub.
419
420	### Languages and their setup actions
421
422	Each language below is on `PATH` from the job's first step, so a workflow
423	that only runs `java`, `dotnet` or `ruby` needs no setup step. When it has
424	one, the setup action finds the version that is already there and
425	downloads nothing.
426
427	\| Language \| Version \| Where \| Setup action \|
428	\| --- \| --- \| --- \| --- \|
429	\| Java \| Eclipse Temurin 21 (LTS), JDK \| `JAVA_HOME` (also `JAVA_HOME_21_X64`), in `RUNNER_TOOL_CACHE` \| `actions/setup-java` with `distribution: temurin` and `java-version: 21` uses it. Other versions and distributions are downloaded. \|
430	\| .NET \| SDK 8 (LTS) \| `DOTNET_ROOT`, `/usr/share/dotnet` \| `actions/setup-dotnet` with `dotnet-version: 8.0.x` keeps it when it is the newest 8.0 SDK, and installs other SDKs beside it. \|
431	\| Ruby \| 3.3, with Bundler \| in `RUNNER_TOOL_CACHE` \| `ruby/setup-ruby` with `ruby-version: '3.3'` (or a `.ruby-version` naming 3.3) uses it. \|
432	\| Node \| 24 \| `/usr/local/bin` \| `actions/setup-node` installs other versions. \|
433	\| Python \| 3.11 \| `/usr/bin/python3` \| `actions/setup-python` installs other versions. \|
434	\| Go \| 1.27 \| `/usr/local/go` \| `actions/setup-go` installs other versions. \|
435	\| Rust \| stable, with `rustfmt`, `clippy` and the `wasm32-unknown-unknown` target \| `~/.cargo/bin` \| `rustup` is there to add toolchains and targets. \|
436
437	```yaml
438	steps:
439	- uses: actions/checkout@v5
440	- uses: actions/setup-java@v5
441	with:
442	distribution: temurin
443	java-version: 21
444	- run: ./gradlew build
445	```
446
447	Because the sandbox runs Debian, `ruby/setup-ruby` treats it as a
448	self-hosted runner and uses only the Rubies in `RUNNER_TOOL_CACHE`. A version other than 3.3 fails at that step; install
449	it in a `run` step instead (for example with `ruby-build`) or run the job
450	in a `container:` with the Ruby you need, such as `ruby:3.4`.
451
452	The headers that gems and .NET need to build native code (`libyaml`,
453	`libffi`, `zlib`, OpenSSL, ICU) are installed too.
454
455	### Calling g1t's API from a job
456
457	The `gh` command is not installed: it needs a GraphQL API, and g1t's API
458	is REST. Call it with `curl`, using the job's token and the API's address,
459	which every job has as `GITHUB_API_URL`:
460
461	```yaml
462	- name: Comment on the pull request
463	env:
464	TOKEN: ${{ github.token }}
465	run: \|
466	curl -fsS -X POST "$GITHUB_API_URL/repos/$GITHUB_REPOSITORY/issues/${{ github.event.number }}/comments" \
467	-H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
468	-d '{"body": "Built."}'
469	```
470
471	The token reaches this repository and does what the job's `permissions:`
472	say; see [the job's token](#the-jobs-token). The
473	[API reference](/reference/api/) lists every endpoint.
474
475	### Machine sizes
476
477	A job runs on the standard machine unless its `runs-on` names a larger
478	one:
479
480	\| `runs-on` \| vCPUs \| Memory \| Disk \|
481	\| --- \| --- \| --- \| --- \|
482	\| `ubuntu-latest`, or any other Linux label \| 0.5 \| 4 GiB \| 8 GB \|
483	\| `g1t-2core` \| 2 \| 8 GiB \| 16 GB \|
484	\| `g1t-4core` \| 4 \| 12 GiB \| 20 GB \|
485
486	```yaml
487	jobs:
488	build:
489	runs-on: g1t-4core
490	```
491
492	The label can come from the matrix or the run's inputs
493	(`runs-on: ${{ matrix.big && 'g1t-4core' \|\| 'ubuntu-latest' }}`). A
494	larger machine costs what it costs g1t, plus the same margin as all
495	sandbox time: see [usage and billing](/guides/usage-and-billing/#workflow-jobs-on-larger-machines).
496	Builds that compile, such as Rust or a large TypeScript project, finish
497	several times faster on one.
498
499	A job on g1t's machines runs for at most 60 minutes, whatever its
500	`timeout-minutes`, and the workflow's page warns about a job that asks
501	for more. One on a self-hosted runner runs for 360 minutes when it names
502	no `timeout-minutes`, as on GitHub, and can ask for up to 24 hours. A job
503	stopped at its time cap fails saying so.
504
505	g1t's machines are x64. A job whose `runs-on` names an Arm label, such
506	as `ubuntu-24.04-arm`, runs on x64, and the workflow's page says so; a
507	self-hosted Arm runner runs it on Arm.
508
509	### What a job can reach
510
511	A job's network is restricted, as an agent's is (see
512	[guardrails](/guides/guardrails/)): it reaches the hosts its project's
513	guardrails allow, g1t itself, and what builds need, and nothing else.
514	What builds need is the package registries (npm, PyPI, crates.io, the Go
515	proxy, RubyGems, Packagist, NuGet, Maven and Gradle, Debian's mirrors),
516	GitHub, where `uses:` actions and the setup actions' downloads come from,
517	the toolchains' download sites (`nodejs.org`, `go.dev`,
518	`static.rust-lang.org`), and the public container registries (Docker Hub,
519	GitHub's, Quay, and `mirror.gcr.io`, the mirror of Docker Hub that a job's
520	Engine asks first). A request anywhere else gets `403` with
521	the reason. To reach another host, someone with the Maintain [role](/guides/access-and-roles/) or
522	higher adds it to the project's
523	allowed domains under Settings → Guardrails; a project whose guardrails
524	turn the network restriction off runs its jobs with an open network.
525
526	A host only workflows should reach, such as the API a deploy uploads to,
527	goes in Workflow-only domains instead, limited to the workflows and
528	environments that need it: `api.cloudflare.com \| deploy.yml \| production`
529	lets only `deploy.yml`'s jobs with `environment: production` reach it.
530	Agents never reach those hosts, and neither do runs of pull requests from
531	forks. See [workflow-only domains](/guides/guardrails/#workflow-only-domains).
532
533	g1t does not run cryptocurrency miners: a step that names one (`xmrig`,
534	a `stratum+tcp://` pool, `--donate-level`) is not run, and a job that
535	looks like it is mining is stopped. See
536	[abuse and mining](/guides/guardrails/#abuse-and-mining).
537
538	## Docker
539
540	Each job on g1t's machines has a Docker Engine of its own, inside the
541	job's sandbox. Nothing runs until the job uses it: the first `docker`
542	command, or a job's `services:` or `container:`, starts it, in a second
543	or two, and the log says so. It ends with the job, with every image,
544	container and build cache in it. No other job, repository or workspace
545	ever shares it.
546
547	```yaml
548	jobs:
549	test:
550	runs-on: ubuntu-latest
551	services:
552	postgres:
553	image: postgres:17
554	env:
555	POSTGRES_PASSWORD: ${{ secrets.DB_PASSWORD }}
556	ports: ["5432:5432"]
557	options: >-
558	--health-cmd pg_isready --health-interval 5s --health-retries 10
559	steps:
560	- uses: actions/checkout@v5
561	- run: docker compose up -d --wait
562	- run: npm test
563	env:
564	DATABASE_URL: postgres://postgres:${{ secrets.DB_PASSWORD }}@localhost:5432/postgres
565	```
566
567	### What works
568
569	\| \| On g1t's machines \|
570	\| --- \| --- \|
571	\| `docker build`, `buildx build`, `run`, `exec`, `pull`, `push`, `login`, `compose` \| Work as they do on GitHub's runners. The Engine, Buildx and Compose are current releases. \|
572	\| `services:` \| Pulled and started before the first step, with `env`, `ports`, `volumes`, `options` and `credentials`. Services with a health check are waited for; one that turns unhealthy fails the job with its log. Each service's log is printed when the job ends. `job.services.<id>.id`, `.network` and `.ports` are set. \|
573	\| `container:` \| Every `run` step and JavaScript action runs inside the image, with its `env`, `options`, `volumes` and `credentials`. The workspace, `RUNNER_TEMP` and the tool cache are mounted at the same paths as on g1t's runner. \|
574	\| `uses: docker://image` \| Pulled and run, with `with.args` and `with.entrypoint`. \|
575	\| Docker actions \| Built from the action's Dockerfile (or pulled, for `image: docker://…`), and run with its `args`, `env` and `entrypoint`, its inputs as `INPUT_*` variables, and `pre-entrypoint` and `post-entrypoint`. \|
576	\| `docker/setup-buildx-action` \| Selects the job's own Engine as the builder (BuildKit). Its `name`, `driver`, `platforms` and `nodes` outputs are set. `driver`, `driver-opts` and `buildkitd-*` are not used, and the log says so. \|
577	\| `docker/build-push-action` \| Works, with `push`, `load`, `tags`, `labels`, `build-args`, `secrets`, `target`, `provenance` and `sbom`. \|
578	\| `docker/login-action` \| Works, for g1t's registry, Docker Hub, GitHub's registry, Cloudflare's (`registry.cloudflare.com`) and any registry the job can reach. \|
579
580	### Services and the network
581
582	Every container a job starts shares the job's own network, the one its
583	[guardrails](/guides/guardrails/) apply to. So:
584
585	- A service is at `localhost` on its port, from steps and from other
586	containers. `ports: ["5432:5432"]` and `ports: ["5432"]` both mean
587	`localhost:5432`.
588	- A port mapped to another number (`ports: ["6543:5432"]`, or
589	`docker run -p 8080:80`) is forwarded: `localhost:6543` reaches the
590	service's 5432. `job.services.<id>.ports` says which port to use, and
591	`docker inspect` and `docker port` report it.
592	- A service is also reached by its name, as it is from a job
593	container on GitHub: `postgres:5432` works from steps, from the job's
594	container and from any container started later. So do the names of
595	containers and Compose services, and their network aliases.
596	- Two containers cannot listen on the same port. A job with a
597	`redis` service and a Compose file that starts another Redis on 6379
598	gets an error from the second; give one of them another port.
599
600	A container that asks for `--network none` gets none, and
601	`--network container:<name>` shares that container's.
602
603	### Job containers
604
605	With `container:`, the steps run inside the image as its default user,
606	usually `root`. A few things differ from GitHub's runner:
607
608	- The workspace is at the same path as on g1t's runner
609	(`/home/runner/work/…`), not `/__w`. `github.workspace` is correct
610	either way.
611	- JavaScript actions run inside the container with g1t's Node 24, which
612	needs an image with glibc and `libstdc++` (Debian, Ubuntu and most
613	language images have both). In an image without them, such as Alpine,
614	they run beside the container, on g1t's runner, with the same files,
615	and the log says so.
616	- `actions/checkout`, `actions/cache` and the artifact actions run on
617	g1t's runner, with the same files.
618
619	### Building and pushing images
620
621	On g1t's machines, a job is signed in to g1t's container registry from
622	the start, with its own `G1T_TOKEN`, so it can push to and pull from its
623	repository's images without a login step; images of other repositories
624	need this one added under their
625	[Manage Actions access](/guides/packages/#manage-actions-access). A run that gets no secrets is
626	not signed in. See [container registry](/guides/containers/#in-workflows).
627
628	```yaml
629	jobs:
630	image:
631	runs-on: g1t-4core
632	steps:
633	- uses: actions/checkout@v5
634	- uses: docker/setup-buildx-action@v3
635	- uses: docker/build-push-action@v6
636	with:
637	push: true
638	tags: g1t.sh/${{ github.repository }}:${{ github.sha }}
639	cache-from: type=registry,ref=g1t.sh/${{ github.repository }}:buildcache
640	cache-to: type=registry,ref=g1t.sh/${{ github.repository }}:buildcache,mode=max
641	```
642
643	For other registries, sign in with `docker/login-action` or
644	`docker login`, as on GitHub. Docker Hub's images are pulled through its
645	public mirror first, so jobs are rarely held up by Docker Hub's limits on
646	anonymous pulls.
647
648	#### Caching image builds
649
650	The Engine starts empty in every job, so a build's layers are rebuilt
651	unless the job brings a cache:
652
653	- A registry cache (`cache-to: type=registry,ref=…,mode=max`), in g1t's
654	registry or any other, is the simplest and is shared by every branch.
655	- A local cache (`cache-to: type=local,dest=/tmp/buildx-cache`) saved
656	and restored with `actions/cache`, within [the cache's limits](#the-cache).
657	- `type=gha` is not used on g1t yet: Buildx skips it, and the build
658	runs without a cache.
659
660	### Limits
661
662	- Machine. Containers share the job's machine: its vCPUs, memory and
663	disk ([machine sizes](#machine-sizes)). Image builds and databases want
664	`g1t-2core` or `g1t-4core`. `--cpus` and `--memory` limit a container
665	within that.
666	- Disk. Images take room on the job's disk. On a machine whose disk
667	cannot hold layered images, the Engine stores plain copies, which take
668	more room; the log says when it does.
669	- Linux, amd64. Images for other platforms need QEMU's emulators,
670	which g1t's machines do not have set up; `docker/setup-qemu-action` is
671	not supported there yet.
672	- Privileged containers (`--privileged`) run, with no more reach than
673	the job itself has: the job's sandbox is the boundary.
674
675	### How Docker is kept safe
676
677	- One Engine per job. It runs inside the job's own sandbox, a virtual
678	machine of its own, and is gone with it. No Docker socket of g1t's, or of
679	any machine, is shared with a job.
680	- The job's guardrails hold. Containers use the job's network, so a
681	container, a build step or an image pull reaches only what the job may
682	reach. A host off the list gets `403` with the reason, as any step does.
683	- HTTPS keeps working. In a job whose network is restricted, every
684	container and build step is given the certificate the job's HTTPS is
685	checked with, in `/dev/g1t-egress`, and `SSL_CERT_FILE`,
686	`NODE_EXTRA_CA_CERTS`, `REQUESTS_CA_BUNDLE`, `CURL_CA_BUNDLE`, `PIP_CERT`,
687	`GIT_SSL_CAINFO` and `CARGO_HTTP_CAINFO` pointing at it, unless the
688	container sets them itself. None of it is written into an image's layers.
689	Tools that keep their own list of certificates, such as Java's, need it
690	added in the build that uses them.
691	- Short-lived credentials. The registry sign-in uses the run's own
692	token, which ends with the run; `credentials:` for a service or a job
693	container are used for that pull only.
694	- No miners. A container whose image or command names a miner is not
695	created, as a step's script is not run.
696
697	## The cache
698
699	`actions/cache` keeps what a job saves for the repository's later jobs:
700
701	\| \| \|
702	\| --- \| --- \|
703	\| One entry \| Up to 2 GiB, compressed. A larger one is not saved, and the job goes on. \|
704	\| A repository's entries \| Up to 10 GiB together. Saving past it removes the entries restored longest ago. \|
705	\| How long \| Until it has not been restored for 7 days, and at most 28 days after it was saved. \|
706	\| Which branch \| An entry belongs to the branch, tag or pull request whose run saved it. A run restores from its own, then from the branch its pull request merges into, then from the default branch. \|
707	\| Keys \| Written once on each branch: saving under a key that exists there does nothing. On each branch in turn, a restore finds its `key` exactly, else the newest entry whose key starts with one of its `restore-keys`. \|
708	\| `path` \| Files and folders; globs, `**` included; `~/` is the home folder; a line starting with `!` leaves matching paths out. The same key saved for other paths is another entry. \|
709	\| Compression \| zstd. \|
710
711	So a feature branch can read what `main` saved, but `main` never reads
712	what a feature branch saved, and a pull request from outside the
713	repository saves where nothing else ever reads it: nobody can plant an
714	entry that the default branch's builds restore. Actions that cache through the
715	toolkit, such as `actions/setup-node` with `cache: npm`, follow the same
716	rules.
717
718	```yaml
719	- uses: actions/cache@v4
720	with:
721	path: \|
722	~/.cargo/registry/cache
723	target/release
724	!target/**/incremental
725	key: cargo-${{ runner.os }}-${{ hashFiles('Cargo.lock') }}
726	restore-keys: cargo-${{ runner.os }}-
727	```
728
729	Each restore and save says on the job's log how large the entry was and
730	how long it took. A workspace on the plan pays for what its caches and
731	[artifacts](#artifacts) hold (`Actions cache storage` on its statement),
732	at R2's price plus the margin; see
733	[usage and billing](/guides/usage-and-billing/#actions-cache).
734
735	## Artifacts
736
737	`actions/upload-artifact` keeps files a job made with its run, for later
738	jobs, other runs and people:
739
740	\| \| \|
741	\| --- \| --- \|
742	\| One artifact \| Up to 5 GiB, zipped. \|
743	\| A run's artifacts \| Up to 10 GiB together. \|
744	\| How long \| The repository's setting: 14 days unless someone with the Maintain role changes it under Settings → Repository → Artifacts, from 1 to 90 days. `retention-days` asks for fewer days, never more. \|
745	\| Names \| One artifact per name in a run. Uploading a name again fails, unless the upload says `overwrite: true`, which replaces it. A name is up to 256 characters, none of `" : < > \\| * ? \ /`. \|
746	\| `path` \| Files, folders and globs, `**` included; a line starting with `!` leaves matching paths out. Files and folders whose names start with `.` are left out unless `include-hidden-files: true`. \|
747	\| Compression \| `compression-level` 0 (stored) to 9; 6 unless you say. \|
748	\| Outputs \| `artifact-id` (a number), `artifact-url` (its run's page) and `artifact-digest` (the SHA-256 of its zip). \|
749
750	```yaml
751	- uses: actions/upload-artifact@v4
752	with:
753	name: web-dist
754	path: \|
755	dist/
756	!dist/*/.map
757	retention-days: 5
758	compression-level: 9
759	```
760
761	`actions/download-artifact` downloads one by `name` into `path`, or every
762	artifact of the run, each into a folder of its name; `pattern` picks them
763	by name, and `merge-multiple: true` puts them all in one folder.
764	`artifact-ids` picks them by number. With `github-token` and `run-id`, it
765	downloads from another run of the same repository, such as the one a
766	`workflow_run` workflow follows:
767
768	```yaml
769	- uses: actions/download-artifact@v4
770	with:
771	name: web-dist
772	github-token: ${{ secrets.GITHUB_TOKEN }}
773	run-id: ${{ github.event.workflow_run.id }}
774	```
775
776	`actions/upload-artifact/merge` downloads the run's artifacts that match
777	`pattern`, uploads them as one artifact (`name`, `merged-artifacts` unless
778	you say), and deletes them with `delete-merged: true`.
779
780	A run's summary lists its artifacts with their size and when they expire.
781	Anyone who can see the run downloads them there; someone with the Write
782	role can delete one before it expires.
783
784	## Actions built on the toolkit
785
786	`actions/cache` and many other actions save to the cache with GitHub's
787	toolkit, `@actions/cache`: `actions/setup-node`, `actions/setup-python`,
788	`actions/setup-go` and `actions/setup-java` with `cache:`,
789	`Swatinem/rust-cache`, and others. They work on g1t as they are: every job gets `ACTIONS_RUNTIME_TOKEN`, `ACTIONS_CACHE_URL` and
790	`ACTIONS_RESULTS_URL`, and g1t answers the toolkit's requests from the
791	repository's cache.
792
793	- Their entries are the repository's, under [the cache's](#the-cache)
794	limits, and are deleted the same way.
795	- An entry is found by its key and by the version the toolkit names for
796	it, from its paths and compression, as on GitHub: an entry `setup-node`
797	saved is restored by `actions/cache` with the same key and paths, and
798	the other way round.
799	- An entry the toolkit sends whole, which it does below 128 MB, is not
800	saved when it is over 100 MB, the most g1t takes in one request. The
801	step warns and the job goes on.
802	- The toolkit's artifact library refuses to run against any server but
803	github.com, so an action that uploads artifacts with it directly fails
804	with its own message. `actions/upload-artifact`,
805	`actions/download-artifact` and `actions/upload-artifact/merge` work:
806	g1t runs those itself.
807
808	## An action's pre and post
809
810	A JavaScript action's `pre` runs before the job's first step, as on
811	GitHub: each one is a step of its own, Pre and the step's name, in the
812	order of the steps, when its `pre-if` holds (`always()` when it has
813	none). Its `post` runs after the last step, Post and the step's name,
814	last first. What `pre` saves with `GITHUB_STATE` or `::save-state::`
815	reaches the step's main as `STATE_<name>`, and what either saves reaches
816	`post`.
817
818	An action in your repository (`uses: ./…`) is not checked out when the
819	job starts, so its `pre` is not run and the step warns, as on GitHub. An
820	action inside a composite action runs its `pre` right before its main.
821
822	A step that gives an input the action does not declare is warned of:
823	Unexpected input(s) 'foo', valid inputs are ['token', 'path']. The
824	step still runs.
825
826	## Problem matchers
827
828	`::add-matcher::path/to/matcher.json` adds the matchers in a file of
829	GitHub's format, and they read every line of output from then on, for
830	the rest of the job. A line one matches becomes an error, warning or
831	notice annotation, with the file, line, column and message it found, in
832	place of the line in the log.
833
834	```json
835	{
836	"problemMatcher": [
837	{
838	"owner": "my-linter",
839	"pattern": [
840	{
841	"regexp": "^(.+):(\\d+):(\\d+): (error\|warning) (.*)$",
842	"file": 1, "line": 2, "column": 3, "severity": 4, "message": 5
843	}
844	]
845	}
846	]
847	}
848	```
849
850	- A pattern of several lines matches them in order. The last one can
851	set `loop` to match each issue after a header line, as ESLint's
852	stylish output has.
853	- `severity` is the matcher's own default, `error` when it gives none.
854	A severity other than `error`, `warning` or `notice` is no annotation.
855	- A file is kept when it exists in a repository in the workspace, as a
856	path inside it; `fromPath` names the file a relative path is from.
857	- A matcher added with an owner already there takes its place.
858	`::remove-matcher owner=my-linter::` removes it.
859	- Patterns are regular expressions as Rust's `regex` reads them, which
860	has no lookaround or backreferences. A file whose patterns do not
861	read is refused, with an error in the log.
862
863	`::echo::on` shows each workflow command in the log as it is read,
864	until `::echo::off`; with [debug logging](#debug-logging) they are shown
865	from the start.
866
867	## Caching Rust builds
868
869	A checkout gives every file a new modification time, so Cargo compiles
870	your workspace's own crates again even when `target/` was restored from
871	the cache. [sccache](https://github.com/mozilla/sccache) caches each
872	compiler call by what it compiles (the source, the flags, the toolchain
873	and the dependencies), so a crate that did not change comes back from the
874	cache instead. Its GitHub Actions backend works on g1t as it is: it keeps
875	its entries in the repository's cache, under [the cache's](#the-cache)
876	limits and branch rules.
877
878	1. Install sccache, pinned to a release and checked against its checksum.
879	2. Set `RUSTC_WRAPPER: sccache` and `SCCACHE_GHA_ENABLED: "true"`. The
880	job's `ACTIONS_RUNTIME_TOKEN` and `ACTIONS_CACHE_URL` are already in
881	every step's environment; no step needs to export them.
882	3. Set `CARGO_INCREMENTAL: "0"`: sccache does not cache incremental
883	builds, and a fresh checkout gains nothing from them.
884
885	```yaml
886	name: CI
887	on:
888	pull_request:
889	push:
890	branches: [main]
891
892	jobs:
893	test:
894	runs-on: ubuntu-latest
895	env:
896	RUSTC_WRAPPER: sccache
897	SCCACHE_GHA_ENABLED: "true"
898	CARGO_INCREMENTAL: "0"
899	steps:
900	- uses: actions/checkout@v5
901	- name: Install sccache
902	env:
903	VERSION: v0.18.0
904	SHA256: 45f1447fbe231e3037bde351ef70677dd212216c8d62ae7ca409fecc4d6acc89
905	run: \|
906	name="sccache-$VERSION-x86_64-unknown-linux-musl"
907	curl -fsSL -o "$RUNNER_TEMP/sccache.tar.gz" \
908	"https://github.com/mozilla/sccache/releases/download/$VERSION/$name.tar.gz"
909	echo "$SHA256 $RUNNER_TEMP/sccache.tar.gz" \| sha256sum -c -
910	tar -xzf "$RUNNER_TEMP/sccache.tar.gz" -C "$RUNNER_TEMP"
911	install -m 0755 "$RUNNER_TEMP/$name/sccache" "$HOME/.cargo/bin/sccache"
912	- run: cargo test --workspace --locked
913	- name: sccache's hits and misses
914	if: always()
915	run: \|
916	echo '```' >> "$GITHUB_STEP_SUMMARY"
917	sccache --show-stats \| tee -a "$GITHUB_STEP_SUMMARY"
918	echo '```' >> "$GITHUB_STEP_SUMMARY"
919	```
920
921	What to expect:
922
923	\| \| \|
924	\| --- \| --- \|
925	\| What is cached \| Every library crate (`rlib`): your workspace's crates and their dependencies. \|
926	\| What is compiled each time \| What rustc links: binaries, `cdylib` crates, proc macros, build scripts and test harnesses. \|
927	\| Its entries \| One per compiled crate, often thousands for a workspace, each a few KB to a few MB. They count toward the repository's 10 GiB like any other entry, and the ones not restored for 7 days are deleted. \|
928	\| Branches \| A pull request reads what the default branch saved. Run the workflow on pushes to the default branch too, as above, or each pull request's first run starts with an empty cache. \|
929	\| Starting over \| Set `SCCACHE_GHA_VERSION` to any new value. A new sccache release starts over by itself. \|
930	\| If the cache cannot be reached \| sccache refuses to start. Set `SCCACHE_IGNORE_SERVER_IO_ERROR: "1"` to have rustc run without it instead. \|
931
932	sccache adds to `actions/cache` rather than replacing it: keep caching
933	`~/.cargo/registry/cache` and `target/` keyed by `Cargo.lock`, so Cargo
934	does not call rustc at all for dependencies that did not change, and
935	sccache answers the calls it still makes for your own crates.
936	`Swatinem/rust-cache` works the same way.
937
938	## OIDC tokens
939
940	A job can prove which repository, branch and environment it runs for with
941	a short-lived OpenID Connect token signed by g1t, and trade it for a cloud
942	provider's credentials. Nothing long-lived needs to sit in a secret.
943
944	1. Give the job, or the workflow, `permissions: id-token: write`. A job
945	without it gets no token, and neither does a run of a pull request from
946	outside the repository.
947	2. Tell your cloud to trust g1t's issuer for your repository (below).
948	3. Use the provider's own login action, which asks for the token.
949
950	```yaml
951	permissions:
952	id-token: write
953	contents: read
954
955	jobs:
956	deploy:
957	runs-on: ubuntu-latest
958	environment: production
959	steps:
960	- uses: aws-actions/configure-aws-credentials@v4
961	with:
962	role-to-assume: arn:aws:iam::123456789012:role/acme-web-deploy
963	aws-region: us-east-1
964	```
965
966	The job gets `ACTIONS_ID_TOKEN_REQUEST_URL` and
967	`ACTIONS_ID_TOKEN_REQUEST_TOKEN`, which `core.getIDToken()` reads. To ask
968	for a token yourself, name its audience:
969
970	```sh
971	curl -sS -H "Authorization: Bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
972	"$ACTIONS_ID_TOKEN_REQUEST_URL&audience=https://deploy.example.com" \| jq -r .value
973	```
974
975	\| \| \|
976	\| --- \| --- \|
977	\| Issuer \| `https://api.g1t.sh/actions/oidc` \|
978	\| Discovery \| `https://api.g1t.sh/actions/oidc/.well-known/openid-configuration` \|
979	\| Keys \| `https://api.g1t.sh/actions/oidc/.well-known/jwks`, RS256, each with its `kid` \|
980	\| Lifetime \| 5 minutes \|
981	\| Audience \| What the job asks for; `https://g1t.sh/<owner>` when it asks for none \|
982
983	### Claims
984
985	Each token carries the claims GitHub's do, so trust policies written for
986	those read g1t's the same way.
987
988	\| Claim \| Example \|
989	\| --- \| --- \|
990	\| `sub` \| `repo:acme/web:environment:production` for a job with an `environment:`; `repo:acme/web:pull_request` for a pull request's run; otherwise `repo:acme/web:ref:refs/heads/main` (or `refs/tags/v1.2.0`) \|
991	\| `repository`, `repository_owner` \| `acme/web`, `acme` \|
992	\| `repository_id`, `repository_owner_id` \| g1t's ids for them, such as `rep_01kpw0…` \|
993	\| `repository_visibility` \| `public` or `private` \|
994	\| `ref`, `ref_type`, `ref_protected`, `sha` \| `refs/heads/main`, `branch`, `"true"`, the commit \|
995	\| `head_ref`, `base_ref` \| A pull request's branches \|
996	\| `environment` \| The job's environment, when it has one \|
997	\| `event_name` \| `push`, `pull_request`, `workflow_dispatch`, … \|
998	\| `workflow`, `workflow_ref`, `workflow_sha` \| `Deploy`, `acme/web/.g1t/workflows/deploy.yml@refs/heads/main`, the commit \|
999	\| `job_workflow_ref`, `job_workflow_sha` \| The workflow that defines the job: a called workflow's own file \|
1000	\| `run_id`, `run_number`, `run_attempt` \| `run_01kq9c…`, `"12"`, `"1"` \|
1001	\| `actor`, `actor_id` \| Who started the run \|
1002	\| `runner_environment` \| `github-hosted` on g1t's machines, `self-hosted` on yours \|
1003	\| `iss`, `aud`, `jti`, `iat`, `nbf`, `exp` \| As in any OIDC token \|
1004
1005	### AWS
1006
1007	1. Add g1t as an identity provider, under IAM → Identity providers:
1008	provider type OpenID Connect, provider URL
1009	`https://api.g1t.sh/actions/oidc`, audience `sts.amazonaws.com`. Or:
1010
1011	```sh
1012	aws iam create-open-id-connect-provider \
1013	--url https://api.g1t.sh/actions/oidc \
1014	--client-id-list sts.amazonaws.com
1015	```
1016
1017	2. Give the role a trust policy for your repository:
1018
1019	```json
1020	{
1021	"Version": "2012-10-17",
1022	"Statement": [{
1023	"Effect": "Allow",
1024	"Principal": { "Federated": "arn:aws:iam::123456789012:oidc-provider/api.g1t.sh/actions/oidc" },
1025	"Action": "sts:AssumeRoleWithWebIdentity",
1026	"Condition": {
1027	"StringEquals": {
1028	"api.g1t.sh/actions/oidc:aud": "sts.amazonaws.com",
1029	"api.g1t.sh/actions/oidc:sub": "repo:acme/web:environment:production"
1030	}
1031	}
1032	}]
1033	}
1034	```
1035
1036	3. Use `aws-actions/configure-aws-credentials@v4` with `role-to-assume`,
1037	as above.
1038
1039	### Google Cloud
1040
1041	1. Make a workload identity pool and a provider for g1t:
1042
1043	```sh
1044	gcloud iam workload-identity-pools create g1t --location=global
1045	gcloud iam workload-identity-pools providers create-oidc g1t \
1046	--location=global --workload-identity-pool=g1t \
1047	--issuer-uri=https://api.g1t.sh/actions/oidc \
1048	--attribute-mapping="google.subject=assertion.sub,attribute.repository=assertion.repository" \
1049	--attribute-condition="assertion.repository_owner == 'acme'"
1050	```
1051
1052	2. Let the repository act as a service account:
1053
1054	```sh
1055	gcloud iam service-accounts add-iam-policy-binding deploy@acme-prod.iam.gserviceaccount.com \
1056	--role=roles/iam.workloadIdentityUser \
1057	--member="principalSet://iam.googleapis.com/projects/123456789/locations/global/workloadIdentityPools/g1t/attribute.repository/acme/web"
1058	```
1059
1060	3. Use `google-github-actions/auth@v2` with
1061	`workload_identity_provider: projects/123456789/locations/global/workloadIdentityPools/g1t/providers/g1t`
1062	and `service_account`. It asks for the provider's own name as the
1063	audience, which the provider accepts unless you change its allowed
1064	audiences.
1065
1066	### Azure
1067
1068	1. On the app registration or user-assigned managed identity, add a
1069	federated credential with the scenario Other issuer: issuer
1070	`https://api.g1t.sh/actions/oidc`, subject identifier
1071	`repo:acme/web:environment:production`, audience
1072	`api://AzureADTokenExchange`. Or:
1073
1074	```sh
1075	az ad app federated-credential create --id <application id> --parameters '{
1076	"name": "g1t-acme-web-production",
1077	"issuer": "https://api.g1t.sh/actions/oidc",
1078	"subject": "repo:acme/web:environment:production",
1079	"audiences": ["api://AzureADTokenExchange"]
1080	}'
1081	```
1082
1083	2. Give it a role on what it deploys to, as for any identity.
1084	3. Use `azure/login@v2` with `client-id`, `tenant-id` and
1085	`subscription-id`, and no secret.
1086
1087	A federated credential matches the subject exactly: add one per
1088	environment or branch that deploys.
1089
1090	### Cloudflare
1091
1092	Cloudflare's API takes API tokens, not OIDC tokens. Keep a token scoped
1093	to what the workflow deploys in a secret, available to that workflow only
1094	(see [workflow-only domains](/guides/guardrails/#workflow-only-domains)
1095	for limiting where it can be sent).
1096
1097	A Worker of your own can trust g1t's jobs directly, by checking the token
1098	a job sends it against g1t's keys:
1099
1100	```ts
1101	import { createRemoteJWKSet, jwtVerify } from "jose";
1102
1103	const keys = createRemoteJWKSet(new URL("https://api.g1t.sh/actions/oidc/.well-known/jwks"));
1104
1105	export async function fromG1tJob(request: Request): Promise<boolean> {
1106	const token = request.headers.get("authorization")?.replace(/^Bearer /, "") ?? "";
1107	const { payload } = await jwtVerify(token, keys, {
1108	issuer: "https://api.g1t.sh/actions/oidc",
1109	audience: "https://deploy.example.com",
1110	});
1111	return payload.sub === "repo:acme/web:environment:production";
1112	}
1113	```
1114
1115	### npm
1116
1117	npm's trusted publishing and provenance accept OIDC tokens only from the
1118	CI services npm lists, and g1t is not one of them yet. Publish with a
1119	granular access token in a secret instead:
1120
1121	```yaml
1122	- uses: actions/setup-node@v4
1123	with:
1124	node-version: 24
1125	registry-url: https://registry.npmjs.org
1126	- run: npm publish
1127	env:
1128	NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
1129	```
1130
1131	See [What g1t can't do yet](/about/limitations/#no-npm-trusted-publishing-or-provenance).
1132
1133	## Runs and logs
1134
1135	Open a repository's Actions page, in its sidebar. Pick a workflow to
1136	see its runs, run it by hand if it has `workflow_dispatch`, or turn it off
1137	without touching its file.
1138
1139	A run's page opens on its Summary. Its sidebar lists All jobs;
1140	pick one to see its steps and their logs as they are written. Groups
1141	fold, errors and warnings are marked, and secrets are replaced with
1142	`***`. The page keeps itself up to date while the run goes on.
1143
1144	### Live logs
1145
1146	While a job runs, its log reaches the page within about two seconds of
1147	being printed: the runner sends what a step prints every second, and the
1148	page asks for more every second while a step is running.
1149
1150	- The running step opens by itself, and its timer counts up. Its log
1151	follows the newest line while the end of it is on screen. Scroll up and
1152	it stays where you are, with Jump to latest to go back to the end.
1153	- A step that prints nothing for a while says so under its last line:
1154	Running · no output for 2m 10s, or no output yet before its
1155	first line. The job's header names the step it is on.
1156	- Colour that tools print is shown as they print it: bold, dim, italic,
1157	underline, the 16 terminal colours, 256 colours and 24-bit colour, for
1158	text and background, in both the light and the dark theme. Tools built
1159	on chalk or supports-color colour their output because the job has
1160	`GITHUB_ACTIONS=true`, as on GitHub; others need asking, such as
1161	`CARGO_TERM_COLOR: always` in the step's `env` for cargo. Other escape codes (moving the cursor, clearing a
1162	line) are left out, and a link keeps its text. Search reads the text
1163	without the colour codes.
1164	- Every line is stamped with the time it was printed, as GitHub stamps
1165	it (`2026-10-12T09:41:07.1234567Z`). The clock button beside **Search
1166	logs** shows or hides the times; your browser remembers which.
1167	- A download (the job's `log.txt` and the run's zip) has the time at the
1168	start of every line, as GitHub's downloaded logs do.
1169	- The runner numbers each batch of the log it sends. When it sends a
1170	batch again because g1t's answer didn't reach it, g1t keeps the batch
1171	once, so a line never shows twice.
1172	- If the page cannot reach g1t for a moment, it says **Reconnecting to the
1173	log** and tries again, waiting longer each time up to half a minute.
1174	A tab you are not looking at stops asking, and catches up when you come
1175	back to it.
1176
1177	A cache restore, an artifact upload or download, and other transfers say
1178	how far they have got every few seconds
1179	(`Received 46137344 of 523190823 (8.8%), 43.9 MBs/sec`).
1180
1181	A [self-hosted runner](/guides/self-hosted-runners/) stamps its lines and
1182	writes these headers once it has updated itself to a release that does;
1183	until then its logs show without times.
1184
1185	### What a job's log says
1186
1187	Each job's log reads as GitHub's does:
1188
1189	\| Step \| What it shows \|
1190	\| --- \| --- \|
1191	\| Set up job \| The runner's version and name; the operating system; the runner image (`ImageOS` and `ImageVersion` when the machine's image sets them, and the software g1t's machines have); the machine (hosted or self-hosted, its architecture, CPUs and memory); what the job's [token](#the-jobs-token) may do, under G1T_TOKEN Permissions; the secret source; each action the job uses as it is downloaded, with the commit it resolved to (`Download action repository 'actions/setup-node@v4' (SHA:…)`); and the job's matrix. \|
1192	\| A `run:` step \| A folded group, `Run` and the script's first line, holding the whole script, the shell it ran in (`shell: /usr/bin/bash -e {0}`) and its variables under `env:`, secrets masked. Then what it printed. \|
1193	\| A `uses:` step \| A folded group, `Run owner/repo@ref`, holding its inputs under `with:` (an action's defaults among them) and its variables under `env:`. \|
1194	\| Post steps and Stop containers \| An action's `post`, saving the cache, then the job's containers stopped, as on GitHub. \|
1195	\| Complete job \| The job's outputs as they are set (`Set output 'version'`), and Cleaning up orphan processes: anything the steps started and left running is stopped (`Terminate orphan process: pid (1234) (node)`). The runner finds those processes by `RUNNER_TRACKING_ID`, as GitHub's does, so a process that unsets it is not found. Only on Linux. \|
1196
1197	### The run's summary
1198
1199	The summary holds, top to bottom:
1200
1201	\| Part \| What it shows \|
1202	\| --- \| --- \|
1203	\| The run \| What triggered it and when, who, the commit and its branch (or pull request), how the run stands, how long it took in all, and how many artifacts it kept. \|
1204	\| The jobs graph \| The workflow file and its event (`deploy.yml · on: push`), then every job and how they depend on each other. See [the jobs graph](#the-jobs-graph). \|
1205	\| Annotations \| Every job's errors, warnings and notices, counted by kind, each with the job it came from. Folds away. \|
1206	\| Job summaries \| What each job's steps wrote to `$GITHUB_STEP_SUMMARY`, under `<job> summary`. See [job summaries](#job-summaries). \|
1207	\| Artifacts \| What the run kept, to download. The count in the run's card jumps here. \|
1208
1209	Under Run details in the sidebar, Workflow file opens the
1210	workflow as it was at the run's commit.
1211
1212	### The jobs graph
1213
1214	Jobs are laid out left to right by their `needs:`: a job that needs
1215	nothing starts a row on the left, and each job sits one column to the
1216	right of the furthest job it needs. Within a column, jobs are ordered so
1217	that as few connectors as possible cross.
1218
1219	\| Node \| How it shows \|
1220	\| --- \| --- \|
1221	\| A job \| Its status, its name and how long it took. Click it to open its steps and logs. \|
1222	\| A job that deploys \| Its environment's address (`environment.url`), as a link, under its name. \|
1223	\| A matrix \| One node with how many jobs it made (`test · 6 jobs`) and how they stand together. Click it to list each combination; click one to open it. \|
1224	\| A reusable workflow \| A box under the job that calls it, named with the called file, holding the called workflow's jobs laid out the same way; a matrix of calls shares one box, each call's jobs named with its combination. The jobs that need the calling job connect to the box. \|
1225
1226	Connectors run from a job to each job that needs it. They are red from a
1227	job that failed, and move while the job they lead to is running (they
1228	stay still if your system asks for reduced motion).
1229
1230	A wide graph scrolls sideways inside its card, on a phone as on a desktop.
1231
1232	The sidebar groups jobs the same way: a matrix's jobs, and a called
1233	workflow's jobs, fold under their name.
1234
1235	### Job summaries
1236
1237	Markdown a step appends to the file in `$GITHUB_STEP_SUMMARY` shows on
1238	the run's summary, below the graph, a card per job, in the order its
1239	steps wrote it. The card's title opens the job:
1240
1241	```yaml
1242	- name: Report the tests
1243	if: always()
1244	run: \|
1245	echo "### Test results" >> "$GITHUB_STEP_SUMMARY"
1246	echo "\| Suite \| Passed \| Failed \|" >> "$GITHUB_STEP_SUMMARY"
1247	echo "\| --- \| ---: \| ---: \|" >> "$GITHUB_STEP_SUMMARY"
1248	echo "\| unit \| 41 \| 0 \|" >> "$GITHUB_STEP_SUMMARY"
1249	```
1250
1251	\| What \| How it works \|
1252	\| --- \| --- \|
1253	\| Formatting \| GitHub-flavoured Markdown: tables, task lists, alerts such as `> [!WARNING]`, code blocks, and the HTML GitHub allows. Scripts, styles and event handlers are removed. \|
1254	\| Secrets \| Masked like the log, before the summary leaves the runner. \|
1255	\| Size \| Up to 1 MiB a step. A larger summary is refused with an error in the step's log, as on GitHub. \|
1256	\| Steps \| Up to 20 steps of a job keep a summary; later ones are dropped. \|
1257	\| Actions \| A JavaScript action's `core.summary` writes to the same file, so it works unchanged. \|
1258
1259	Summaries belong to their attempt: an earlier attempt keeps its own.
1260
1261	### Re-running
1262
1263	When a run has finished, someone with the Write role can run it again:
1264
1265	\| Button \| Runs again \|
1266	\| --- \| --- \|
1267	\| Re-run all jobs \| Every job. \|
1268	\| Re-run failed jobs \| Jobs that did not succeed (failed, cancelled or skipped), and every job that needs one of them. \|
1269	\| The re-run button beside a job's name \| That job, and every job that needs it. A job of a matrix runs again with the rest of its matrix; a job of a reusable workflow runs again with the job that calls it. \|
1270
1271	Jobs that are not run again keep how they ended, and their outputs reach
1272	the jobs that need them.
1273
1274	Each re-run is a new attempt. The run keeps its number, `github.run_attempt`
1275	goes up by one, and the attempt before is kept as it ended: its jobs,
1276	their steps, logs and summaries. Pick one from Attempt # at the top of
1277	the page to read it. Its jobs have ids of their own, so a link to an
1278	earlier attempt's job keeps showing that job's log.
1279
1280	#### Debug logging
1281
1282	Each re-run asks whether to Enable debug logging. The new attempt's
1283	jobs then run with:
1284
1285	\| Set \| Effect \|
1286	\| --- \| --- \|
1287	\| `RUNNER_DEBUG=1`, and `runner.debug` is `1` \| Actions that check it, such as the toolkit's `core.isDebug()`, log more. \|
1288	\| `ACTIONS_STEP_DEBUG=true` \| `::debug::` lines are shown in the log. \|
1289	\| `ACTIONS_RUNNER_DEBUG=true` \| Set for actions that read it. \|
1290
1291	With debug logging, each step's log also says how its `if:` read:
1292	`Evaluating condition for step`, the expression, and the result. Setting a
1293	secret or variable named `ACTIONS_STEP_DEBUG` to `true` shows `::debug::`
1294	lines on every run instead. The attempt picker marks attempts that ran
1295	with debug logging.
1296
1297	### Cancelling
1298
1299	Cancel run cancels jobs that have not started at once. A job that is
1300	running is stopped the way GitHub stops one:
1301
1302	1. The step it is on gets `SIGINT`, then `SIGTERM` 7.5 seconds later, and
1303	is killed 2.5 seconds after that. Signals reach the processes the step
1304	started too; in a [job container](#job-containers) they reach only the
1305	`docker exec` that runs the step. The step ends cancelled.
1306	2. Its remaining steps run only if they ask to: `if: always()` or
1307	`if: cancelled()`. Steps without an `if:`, or with `success()` or
1308	`failure()`, are skipped.
1309	3. Post steps (an action's `post`, saving the cache) run, as their
1310	`post-if` is `always()` unless the action says otherwise.
1311	4. The job ends cancelled, whatever those steps came to.
1312
1313	While that happens the run says Cancelling. A job still going 5
1314	minutes after it was cancelled is stopped outright. Force cancel
1315	(shown while a run is cancelling) stops every job at once, without
1316	waiting for its cleanup steps.
1317
1318	A step learns of a cancellation within about 10 seconds, even when it
1319	prints nothing. A job on a [self-hosted runner](/guides/self-hosted-runners/)
1320	is stopped the same way.
1321
1322	### Searching and downloading logs
1323
1324	The Search logs box above a job's steps shows only the lines that hold
1325	what you type, in any case, with each match marked and every step that has
1326	one opened. Lines inside folded groups are searched too.
1327
1328	\| Download \| Where \|
1329	\| --- \| --- \|
1330	\| One job's whole log, as text \| The download button beside the job's name. \|
1331	\| Every job's log of an attempt, as a zip \| Download logs at the top of the run. The zip holds `1_<job>.txt` with each job's whole log, and a `<job>/` folder with `<step>_<step name>.txt` for each step. \|
1332
1333	A zip holds up to 24 MiB of logs; jobs past that are listed with a note
1334	to download them on their own. Each job keeps up to 4 MB of log.
1335
1336	### Status badges
1337
1338	A badge shows how a workflow's latest finished run went: passing,
1339	failing, cancelled, or no status before it has finished one.
1340
1341	1. Open the repository's Actions page and pick the workflow.
1342	2. Click Create status badge.
1343	3. Choose a branch and an event, if you want them, and copy the Markdown.
1344
1345	```markdown
1346	[![CI](https://g1t.sh/acme/web/actions/workflows/ci.yml/badge.svg)](https://g1t.sh/acme/web/actions?workflow=ci.yml)
1347	```
1348
1349	The address is `https://g1t.sh/{workspace}/{repo}/actions/workflows/{file}/badge.svg`,
1350	where `{file}` is the workflow's file name in `.g1t/workflows/`. It takes:
1351
1352	\| Parameter \| Shows \|
1353	\| --- \| --- \|
1354	\| `branch` \| Runs on that branch. Without it, the default branch's runs, or any branch's when the default branch has none. \|
1355	\| `event` \| Runs started by that event, such as `push` or `pull_request`. \|
1356
1357	A public repository's badge loads for anyone and is cached for a minute.
1358	A private repository's loads only for someone who can see the repository,
1359	so it does not show in a README read anywhere else.
1360
1361	### Masking secrets
1362
1363	Every secret's value is replaced with `***` wherever a job prints it, and
1364	so is every value a step masks with `::add-mask::`. Each is masked in the
1365	forms it shows up in:
1366
1367	\| Form \| Example \|
1368	\| --- \| --- \|
1369	\| As it is \| `echo $API_KEY` \|
1370	\| Each of its lines on its own \| `cat key.pem`, which prints a private key a line at a time \|
1371	\| Base64 \| `echo -n $API_KEY \\| base64`, or an `Authorization: Basic` header \|
1372	\| JSON-escaped \| A secret holding quotes or newlines printed inside JSON \|
1373
1374	Annotations' titles and messages, and step names, are masked the same way.
1375	A job output that holds a secret in any of those forms is left out, with
1376	a warning in the log, since outputs go to other jobs and to the run's page.
1377	A value of one character is not masked: it would hide that character
1378	everywhere.
1379
1380	## Pull requests
1381
1382	A pull request's workflows run on each new head: when it is opened, when
1383	a commit is pushed to it, and, for one g1t makes, when g1t
1384	marks it ready, which on g1t is when it first has code. Each head runs
1385	each workflow once.
1386
1387	They also start on the activity types `reopened` (also run by
1388	default, as `opened` and `synchronize` are), `converted_to_draft`,
1389	`ready_for_review`, `labeled`, `unlabeled`, `milestoned`, `demilestoned`,
1390	`assigned`, `review_requested` and `closed`, and `edited` when the branch
1391	a pull request merges into changes; `issue_comment` workflows on
1392	`created`, `edited` (with `github.event.changes.body.from`) and `deleted`; `issues` workflows on `assigned`, `labeled`, `unlabeled`, `milestoned` and
1393	`demilestoned` too. List them under `types:` to run on them. For
1394	`labeled` and `unlabeled`, `github.event.label` names the label; for
1395	`assigned`, `github.event.assignee` names who was assigned. Assigning
1396	several people at once starts one run, which names the first of them. A pull
1397	request's `branches` filter, `github.base_ref` and
1398	`pull_request.base.ref` are the branch it merges into, which is not
1399	always the default branch: see
1400	[pull requests into other branches](/guides/base-branches/).
1401
1402	A pull request from outside the workspace may wait for approval before
1403	its workflows run: see [pull requests from outside](#pull-requests-from-outside).
1404
1405	`github.event.pull_request` reads as it does on GitHub. For a pull request
1406	g1t made, `pull_request.user` is g1t (`login` `g1t`, `type` `Bot`), and
1407	`pull_request.requested_by` names the person who asked for it; it is `null`
1408	on anyone else's. `github.event.issue.requested_by` does the same for an
1409	issue g1t's agent filed. `sender` is whoever caused the event.
1410
1411	## Checks
1412
1413	A pull request's checks are its workflows. Each workflow that runs on
1414	`pull_request` runs on every pull request's head, whoever opened it, a
1415	person or an agent, and its runs report a check named after the workflow:
1416	a workflow with `name: CI` reports `CI`, with the status context
1417	`CI / pull_request` (the workflow's name and the event). Each of its jobs
1418	is a [check run](/guides/checks/) on the commit, shown as
1419	`CI / test (pull_request)` beside it wherever it appears.
1420
1421	- Which checks a merge needs is up to the [rules](/guides/rules/) of the branch it merges into,
1422	their [required status checks](/guides/pull-requests/#required-status-checks),
1423	under Settings → Rules. A required check that failed,
1424	is still running or has not reported holds the merge. Checks that are not
1425	required are shown on the pull request and never hold it.
1426	- In a repository that merges through the [merge queue](/guides/merge-queue/),
1427	workflows with `on: merge_group` run on each combined state the queue
1428	builds, on the branch `g1t-queue/<entry>`, and the state lands only if
1429	they and every required check pass on it. A workflow behind a required
1430	check needs `merge_group` in its `on:`.
1431	- A pull request g1t is working on goes back to g1t when
1432	a check fails, with the end of each failed job's log. The agent reads the
1433	run and its logs with the same tools you have, fixes the cause, and
1434	pushes; the workflows run again. See
1435	[seeing it through](/guides/working-with-g1t/#seeing-it-through).
1436
1437	```yaml
1438	name: CI
1439
1440	on:
1441	pull_request:
1442	push:
1443	branches: [main]
1444	merge_group:
1445	```
1446
1447	### Add CI
1448
1449	A repository with no workflows has nothing that proves a change works, for
1450	people or for agents. Its pull requests, its Branches and merging
1451	settings and its Actions page say This repository has no checks,
1452	with an Add CI button. Anyone who can push to the repository can use it:
1453
1454	1. Choose Add CI. g1t looks at the files at the repository's root and
1455	writes a starter workflow with a job for each stack it finds, up to
1456	three: Node (npm, pnpm, Yarn or Bun), Rust, Go, Python (pip or uv), Ruby,
1457	Java (Maven or Gradle), .NET, or Make. Each job installs, lints where
1458	the project says how, builds and tests. When it finds none, the job is a
1459	placeholder that fails until you replace its last step with your own
1460	commands.
1461	2. The workflow is committed as `.g1t/workflows/ci.yml` on a new branch,
1462	`add-ci`, and opened as a pull request, by you. It is named `CI` and runs
1463	on `pull_request`, on `push` to the default branch, and on `merge_group`.
1464	3. Change it on the pull request if the steps are not how your project
1465	builds, and merge it.
1466	4. Once it has run, `CI` is offered under **Require status checks to pass
1467	before merging**.
1468	Require it, so that nothing merges into the default branch unless it
1469	passes.
1470
1471	## Secrets and variables
1472
1473	Secrets are read as `${{ secrets.KEY }}` and config as `${{ vars.KEY }}`,
1474	from the rows under Settings → Secrets and variables that are
1475	available to Workflows. A job with `environment: production` reads each
1476	key's Production row; other jobs read the rows for all environments. A
1477	job with an `environment:` also makes a deployment to it; see
1478	[deployments from g1t Actions](/guides/deployments-api/#deployments-from-g1t-actions). See
1479	[Secrets and variables](/guides/secrets-and-variables/) for how rows,
1480	environments and the workspace's rows work.
1481
1482	Every job also gets `${{ secrets.G1T_TOKEN }}`, [its own token](#the-jobs-token),
1483	with `GITHUB_TOKEN` as its alias. A pull request's runs get secrets only
1484	when its author has the Write [role](/guides/access-and-roles/) or higher
1485	on the repository, a member or an outside collaborator, or is g1t working
1486	on its own. For a pull request g1t made, its author is g1t and the person
1487	who asked for it is the one whose role counts. Anyone else's, such as one
1488	from a fork or by someone with Read or Triage, runs without secrets and
1489	with a token that can only read. See
1490	[who gets secrets](/guides/secrets-and-variables/#who-gets-secrets).
1491
1492	## The job's token
1493
1494	Each job gets a token of its own, `${{ secrets.G1T_TOKEN }}`
1495	(`${{ secrets.GITHUB_TOKEN }}` and `${{ github.token }}` are the same).
1496	`actions/checkout` uses it, and so can any step that calls the
1497	[API](/reference/api/) or pushes with git:
1498
1499	- It reaches this repository only. Every other repository, even one
1500	in the same workspace, is refused. So are packages: it reaches this
1501	repository's own, and another package only once the package's admins
1502	add this repository under its
1503	[Manage Actions access](/guides/packages/#manage-actions-access).
1504	- It can do what its `permissions:` say, and nothing more.
1505	- It stops working when the job ends, however it ends.
1506	- Everything it changes is in the [audit log](/guides/audit-log/) as that
1507	job's, under its run.
1508	- What it changes starts no workflows: a push, a pull request, an issue
1509	or a comment made with it runs nothing, so a workflow cannot set itself
1510	off. `workflow_dispatch` and [`repository_dispatch`](#repository-dispatch)
1511	are the exceptions, for a workflow that means to start another.
1512	- It never puts g1t to work. A comment it posts that mentions
1513	`@g1t` starts nothing, and it cannot assign an issue or a plan to g1t,
1514	queue one for it, hand it work or ask it for a review. Otherwise a
1515	workflow that asks g1t to fix a failing check would run again on g1t's
1516	push, and ask again, without end. A step that should put g1t to work
1517	uses a token of a person's own, stored as a
1518	[secret](/guides/secrets-and-variables/).
1519
1520	`permissions:` goes at the top of the workflow, for every job, or on a job,
1521	which then ignores the workflow's. Once either is written, every permission
1522	it leaves out is `none`:
1523
1524	```yaml
1525	permissions:
1526	contents: read
1527
1528	jobs:
1529	release:
1530	runs-on: ubuntu-latest
1531	permissions:
1532	contents: write
1533	pull-requests: write
1534	steps:
1535	- uses: actions/checkout@v5
1536	- run: ./scripts/release.sh
1537	```
1538
1539	\| Permission \| `read` lets it \| `write` also lets it \|
1540	\| --- \| --- \| --- \|
1541	\| `contents` \| Clone and fetch with git, read the repository \| Push, publish releases \|
1542	\| `pull-requests` \| Read pull requests \| Open, review, close and merge them \|
1543	\| `issues` \| Read issues \| Open, edit, comment on and close them \|
1544	\| `actions` \| Read workflows, runs and logs \| Run, cancel and re-run them \|
1545	\| `checks`, `statuses` \| Read statuses and check runs \| Report them \|
1546	\| `deployments`, `pages` \| Read deployments \| Report them \|
1547	\| `packages` \| Pull packages \| Push and publish them \|
1548	\| `security-events` \| Read security alerts \| Upload code scanning results, change alerts \|
1549	\| `metadata` \| Always `read` \| \|
1550	\| `id-token` \| Nothing \| Ask for an [OIDC token](#oidc-tokens) \|
1551	\| `discussions`, `attestations`, `models`, `repository-projects` \| Nothing on g1t \| Nothing on g1t \|
1552
1553	`read-all` and `write-all` set every permission; `permissions: {}` sets
1554	none, so the token cannot even clone a private repository. A reusable
1555	workflow's jobs get no more than the job that calls it.
1556
1557	There is no `workflows` permission for a job's token: it can never add,
1558	change or delete a file under `.g1t/workflows/` or `.github/workflows/`,
1559	even with `contents: write`. A push that does is declined, naming the file,
1560	so a workflow cannot rewrite the workflows that run with its repository's
1561	secrets. To change workflows from a job, push with a
1562	[personal access token](/guides/authentication/#workflow-files) that has
1563	Workflow files: write, kept as a secret.
1564
1565	The job's token is the repository's workspace acting with the Write role
1566	at most, never Admin: it cannot manage webhooks, secrets, deploy keys or who
1567	has access, whatever it asks for.
1568
1569	Without `permissions:` a job gets the repository's default, which
1570	someone with the Admin role sets under Settings → Actions:
1571
1572	\| Repository \| Default until someone chooses \|
1573	\| --- \| --- \|
1574	\| Made before restricted tokens came in, in October 2026 \| Read and write: every permission at `write`, as before \|
1575	\| Made since \| The workspace's default for new repositories: Read repository contents and packages (`contents: read`, `packages: read`) unless an owner chose otherwise \|
1576
1577	The workspace's owners set that default, and a maximum, under the
1578	workspace's Settings → Actions: with a maximum of Read only, no
1579	repository's default goes past `contents: read` and `packages: read`,
1580	whatever it chose. Workflows that write `permissions:` get what they
1581	write either way, and whatever a workflow asks for, a pull request from
1582	outside the repository's writers (a fork, or someone with Read or Triage)
1583	gets a token that can only read.
1584
1585	Allow g1t Actions to create and approve pull requests is off unless a
1586	repository's admin turns it on under Settings → Actions, and they can
1587	only where the workspace's owners allow it. Until then a job's token
1588	cannot open a pull request or approve one, whatever its `pull-requests`
1589	permission says; it can still read, comment on, review with changes
1590	requested, and merge them.
1591
1592	The token can never change secrets, variables, environments' rules or
1593	the Actions settings, approve runs or deployments, or reach another
1594	repository.
1595
1596	## Environments
1597
1598	A job that names an environment with `environment:` reads that
1599	environment's [secrets and variables](/guides/secrets-and-variables/#a-value-per-environment)
1600	and records a [deployment](/guides/deployments-api/#deployments-from-g1t-actions)
1601	to it. Give the environment protection rules, and such a job waits until
1602	they let it through, and only then gets the environment's secrets:
1603
1604	\| Rule \| What it does \|
1605	\| --- \| --- \|
1606	\| Required reviewers \| Up to 6 people or teams. The job waits until one of them approves it. \|
1607	\| Prevent self-review \| Whoever started the run cannot approve it, even as a reviewer. \|
1608	\| Wait timer \| Minutes the job waits once it reaches the environment, up to 43,200 (30 days). \|
1609	\| Deployment branches and tags \| All branches; Protected branches only, those the repository's [rules](/guides/rules/) protect, the default branch included; or Selected branches and tags, by pattern, such as `main`, `release/` or `v`. A job on any other ref fails, saying so. A pull request's run is on no branch, so it can deploy only where all branches may. \|
1610	\| Allow admins to bypass \| On unless you turn it off: someone with the Admin role may approve without being a reviewer, which also skips the wait timer. \|
1611
1612	To set them:
1613
1614	1. Open the repository's Settings → Environments. It lists every
1615	environment your workflows, secrets and deployments name.
1616	2. Choose one, or name a new one, and set its rules.
1617	3. Save. Runs that reach the environment from then on wait by them.
1618
1619	A run whose jobs wait shows Waiting for review at the top of its page,
1620	with the environments, the jobs each holds, its reviewers and when its
1621	wait timer runs out. Reviewers are told in their [notifications](/guides/notifications/);
1622	on the run's page they choose Approve and deploy or Reject, with
1623	room for a comment. One review covers every job of the run that names the
1624	environment. A rejected job fails, and so does anything that needs it. The
1625	rest of the run goes on meanwhile: jobs that do not need the waiting ones
1626	run.
1627
1628	The environment's name may be an expression, such as
1629	`environment: ${{ inputs.target }}`: it is read once the job's needs are
1630	done, and its rules and secrets are that environment's. Names are matched
1631	without regard to case.
1632
1633	From the API, `PUT /repos/{owner}/{repo}/environments/{environment}` sets
1634	the rules, with `reviewers`, `prevent_self_review`, `wait_timer`,
1635	`deployment_branch_policy`, `branch_policies` and `can_admins_bypass`;
1636	`GET` on the same route returns them as `protection_rules`; `DELETE`
1637	removes them. `POST /repos/{owner}/{repo}/actions/runs/{id}/pending_deployments`
1638	approves or rejects a run's waiting jobs:
1639
1640	```sh
1641	curl -X PUT https://api.g1t.sh/repos/acme/web/environments/production \
1642	-H "Authorization: Bearer $G1T_TOKEN" -H "Content-Type: application/json" \
1643	-d '{"reviewers": [{"type": "Team", "name": "deployers"}], "wait_timer": 10,
1644	"deployment_branch_policy": {"protected_branches": true, "custom_branch_policies": false}}'
1645	```
1646
1647	A job's own token cannot approve, reject or change any of it.
1648
1649	## Pull requests from outside
1650
1651	A pull request from someone outside the workspace runs code anyone could
1652	have written. By the repository's approval policy, its runs wait as
1653	Approval required until someone with the Write
1654	[role](/guides/access-and-roles/) chooses Approve and run on the run's
1655	page. Nothing runs before then: no job starts, and no token or secret is
1656	handed out.
1657
1658	\| Policy, under Settings → Actions \| Whose pull requests' runs wait \|
1659	\| --- \| --- \|
1660	\| First-time contributors \| Someone outside the workspace who has not had a pull request merged here yet. \|
1661	\| Outside contributors (the default) \| Those, and everyone outside the workspace who cannot push here: pull requests from forks, and from people with Read or Triage. \|
1662	\| All external contributors \| Everyone outside the workspace, [outside collaborators](/guides/access-and-roles/#outside-collaborators) with Write included. \|
1663
1664	Members' pull requests never wait, nor do pull requests g1t opens on its
1665	own. For a pull request g1t made for someone, that person is the one whose
1666	policy counts. Each new push to the pull request waits again.
1667	`pull_request_target` runs, which run the default branch's workflow and
1668	code, never wait.
1669
1670	From the API: `POST /repos/{owner}/{repo}/actions/runs/{id}/approve`
1671	approves a run, and `GET` and `PUT
1672	/repos/{owner}/{repo}/actions/permissions/fork-pr-contributor-approval`
1673	read and set the policy, as `approval_policy`.
1674
1675	## Repository dispatch
1676
1677	`POST /repos/{owner}/{repo}/dispatches` starts the default branch's
1678	workflows that run `on: repository_dispatch` for its `event_type`, those
1679	listing it under `types:` or listing none. `client_payload` is theirs to
1680	read as `github.event.client_payload`:
1681
1682	```yaml
1683	on:
1684	repository_dispatch:
1685	types: [docs-published]
1686
1687	jobs:
1688	announce:
1689	runs-on: ubuntu-latest
1690	steps:
1691	- run: echo "Docs ${{ github.event.client_payload.version }} are out"
1692	```
1693
1694	```sh
1695	curl -X POST https://api.g1t.sh/repos/acme/web/dispatches \
1696	-H "Authorization: Bearer $G1T_TOKEN" -H "Content-Type: application/json" \
1697	-d '{"event_type": "docs-published", "client_payload": {"version": "2.4.0"}}'
1698	```
1699
1700	It needs the Write role, or a token with `code:write`; a job's own token
1701	needs `contents: write`. `client_payload` is a JSON object of at most 10
1702	properties and 64 KB.
1703
1704	## Who may run workflows
1705
1706	What you can do with a repository's workflows follows your
1707	[role](/guides/access-and-roles/) on it:
1708
1709	\| \| Needs \|
1710	\| --- \| --- \|
1711	\| See workflows, runs and their logs \| Read: on a public repository, anyone \|
1712	\| Run a workflow by hand, cancel or re-run a run, approve a pull request's run from outside \| Write \|
1713	\| Approve or reject a job waiting for an environment \| One of the environment's reviewers \|
1714	\| Enable or disable a workflow \| Maintain \|
1715	\| The repository's secrets and variables, seeing them included; environments' rules; Settings → Actions \| Admin \|
1716
1717	Jobs run in g1t's sandboxes, so they need the
1718	[g1t plan](/guides/usage-and-billing/#the-g1t-plan) or
1719	[the trial](/guides/usage-and-billing/#the-trial); jobs on
1720	[self-hosted runners](/guides/self-hosted-runners/#billing) need neither.
1721	On a public repository,
1722	[g1t's open-source pool](/guides/usage-and-billing/#the-open-source-pool)
1723	runs them too, after a card check, until the month's pool is spent.
1724
1725	Before each job starts, g1t reserves what it may cost (its time limit at
1726	the sandbox price) with billing, and settles what it really cost when it
1727	ends; each job's sandbox is charged as
1728	[sandbox time](/guides/usage-and-billing/#sandbox-time), from the first
1729	second. A job billing refuses does not start: it is recorded as failed
1730	with "Not started:" and the reason, such as "Workflows run in g1t's
1731	sandboxes, which cost real money, so they need the g1t plan ($20 a month)
1732	or a card check", and what to do about it. The
1733	Actions page tells people with Write on a repository whose workspace
1734	cannot run jobs before the first run.
1735
1736	## From the API
1737
1738	The routes follow the standard Actions REST shape, so existing scripts
1739	usually work once they point at `https://api.g1t.sh`.
1740
1741	\| `workflow` action \| Route \|
1742	\| --- \| --- \|
1743	\| `list` \| `GET /repos/{owner}/{repo}/actions/workflows` \|
1744	\| `list_runs` \| `GET /repos/{owner}/{repo}/actions/runs`, with `workflow`, `branch`, `event`, `pull`, `head_sha` \|
1745	\| `get_run` \| `GET /repos/{owner}/{repo}/actions/runs/{id}` \|
1746	\| `job_logs` \| `GET /repos/{owner}/{repo}/actions/jobs/{job}/logs?after=`, or `?format=text` for the whole log as plain text \|
1747	\| `get_run` with `attempt` \| `GET /repos/{owner}/{repo}/actions/runs/{id}/attempts/{attempt}` \|
1748	\| No tool: a download \| `GET /repos/{owner}/{repo}/actions/runs/{id}/logs`, or `…/attempts/{attempt}/logs`: every job's log as a zip \|
1749	\| `dispatch` \| `POST /repos/{owner}/{repo}/actions/workflows/{workflow}/dispatches` with `ref` and `inputs` \|
1750	\| `cancel` \| `POST /repos/{owner}/{repo}/actions/runs/{id}/cancel`; `…/force-cancel`, or `force`, to stop running jobs without their cleanup steps \|
1751	\| `rerun` \| `POST …/runs/{id}/rerun`, or `…/rerun-failed-jobs`; one job and those that need it with `POST /repos/{owner}/{repo}/actions/jobs/{job}/rerun`. Each takes `enable_debug_logging` (or `debug`) \|
1752	\| `update` \| `PUT …/workflows/{workflow}/enable` and `…/disable` \|
1753	\| `approve_run` \| `POST /repos/{owner}/{repo}/actions/runs/{id}/approve` \|
1754	\| `pending_deployments` \| `GET /repos/{owner}/{repo}/actions/runs/{id}/pending_deployments` \|
1755	\| `review_deployments` \| `POST /repos/{owner}/{repo}/actions/runs/{id}/pending_deployments` with `environment_names`, `state` and `comment` \|
1756	\| `get_environment` \| `GET /repos/{owner}/{repo}/environments/{environment}` \|
1757	\| `update_environment` \| `PUT /repos/{owner}/{repo}/environments/{environment}` \|
1758	\| `delete_environment` \| `DELETE /repos/{owner}/{repo}/environments/{environment}` \|
1759	\| `get_permissions`, `set_permissions` \| `GET` and `PUT /repos/{owner}/{repo}/actions/permissions/workflow`, with `default_workflow_permissions` (`read`, `write` or `inherit`) and `can_approve_pull_request_reviews` \|
1760	\| `get_workspace_permissions`, `set_workspace_permissions` \| `GET` and `PUT /workspaces/{workspace}/actions/permissions/workflow`, with `default_workflow_permissions`, `max_workflow_permissions` and `can_approve_pull_request_reviews` \|
1761	\| `get_approval_policy`, `set_approval_policy` \| `GET` and `PUT /repos/{owner}/{repo}/actions/permissions/fork-pr-contributor-approval` \|
1762	\| `get_access`, `set_access` \| `GET` and `PUT /repos/{owner}/{repo}/actions/permissions/access`, with `access_level` (`none` or `organization`) \|
1763	\| `repository_dispatch` \| `POST /repos/{owner}/{repo}/dispatches` with `event_type` and `client_payload` \|
1764	\| `list_artifacts` \| `GET /repos/{owner}/{repo}/actions/artifacts`, with `name`, `page`, `per_page` \|
1765	\| `run_artifacts` \| `GET …/actions/runs/{id}/artifacts`, with `name` \|
1766	\| `get_artifact` \| `GET …/actions/artifacts/{artifact_id}` \|
1767	\| `download_artifact` \| `GET …/actions/artifacts/{artifact_id}/zip`: a `302` to a link good for 10 minutes \|
1768	\| `delete_artifact` \| `DELETE …/actions/artifacts/{artifact_id}` \|
1769	\| `artifact_retention`, `set_artifact_retention` \| `GET` and `PUT …/actions/permissions/artifact-and-log-retention` with `days` (it sets artifacts' days only; logs are kept with their run) \|
1770
1771	Secrets and variables have a tool of their own, `secret`:
1772
1773	\| `secret` action \| Route \|
1774	\| --- \| --- \|
1775	\| `list_secrets`, `set_secret`, `delete_secret` \| `GET /repos/{owner}/{repo}/actions/secrets`, `PUT` and `DELETE …/secrets/{name}` \|
1776	\| `list_variables`, `set_variable`, `delete_variable` \| `GET` and `POST /repos/{owner}/{repo}/actions/variables`, `PATCH` and `DELETE …/variables/{name}` \|
1777
1778	Workspace secrets and variables are under
1779	`/workspaces/{workspace}/actions/secrets` and `…/variables`. The fields
1780	g1t adds (environments, who reads a row, linked repositories) are in
1781	[Secrets and variables](/guides/secrets-and-variables/#from-the-api).
1782
1783	```sh
1784	curl -X POST https://api.g1t.sh/repos/acme/web/actions/workflows/ci.yml/dispatches \
1785	-H "Authorization: Bearer $G1T_TOKEN" -H "Content-Type: application/json" \
1786	-d '{"ref": "main", "inputs": {"environment": "staging"}}'
1787	```
1788
1789	Give only the inputs the workflow declares under
1790	`on.workflow_dispatch.inputs`: a run with any other input is refused, and
1791	the answer names the inputs it did not expect. A `boolean` input is `true`
1792	or `false`, a `number` a number, a `choice` one of its `options`, and an
1793	`environment` the name of one of the repository's
1794	[environments](#environments). In the run, the `inputs` context keeps
1795	booleans and numbers as they are, and `github.event.inputs` has every
1796	input as text, `"true"` and `"3"`, as on GitHub.
1797
1798	To save an artifact from a script, follow the redirect:
1799
1800	```sh
1801	curl -L -o web-dist.zip -H "Authorization: Bearer $G1T_TOKEN" \
1802	https://api.g1t.sh/repos/acme/web/actions/artifacts/4182/zip
1803	```