| 1 | --- |
| 2 | title: Guardrails |
| 3 | description: How long a project's checks, merge queue and merge checks may run on g1t's machines, how a sandbox reaches the internet, and how g1t watches for mining. |
| 4 | --- |
| 5 | |
| 6 | Guardrails decide how long a project's work may run in g1t's sandboxes. A |
| 7 | workspace sets defaults, and each project can override them. |
| 8 | |
| 9 | They apply to the runs g1t starts for a project: its checks, its merge |
| 10 | queue and its merge checks. Actions jobs and deploy builds keep their own |
| 11 | time limits. Every sandbox, whatever it runs, is watched for |
| 12 | [mining](#abuse-and-mining). |
| 13 | |
| 14 | ## Where to set them |
| 15 | |
| 16 | - **Workspace defaults**: the workspace's **Settings**, **Guardrails**. |
| 17 | Owners can change them; members can read them. |
| 18 | - **A project's overrides**: the project's **Settings**, **Guardrails**. |
| 19 | People with the Admin [role](/guides/access-and-roles/) on |
| 20 | its repository can see and change them; the page is not shown to anyone |
| 21 | else. |
| 22 | |
| 23 | A time left empty on a project's page follows the workspace's default, |
| 24 | whatever it is now, shown faded. Enter a number to override it for that |
| 25 | project only. |
| 26 | |
| 27 | Changes apply to runs that start after you save. A run that is under way |
| 28 | keeps the guardrails it started with. Each change is recorded in the |
| 29 | workspace's [audit log](/guides/audit-log/) as `update_guardrails`, saying |
| 30 | which time caps were set, changed or cleared. |
| 31 | |
| 32 | ## Time per run |
| 33 | |
| 34 | How long each kind of run may take, in minutes. By default: |
| 35 | |
| 36 | | Kind of run | Minutes | |
| 37 | | --- | --- | |
| 38 | | Checks | 45 | |
| 39 | | Merge queue | 45 | |
| 40 | | Merge check | 10 | |
| 41 | |
| 42 | At most 240 minutes. A run that reaches its time cap fails, with |
| 43 | "Stopped: it reached its time cap of 45 minutes." The sandbox is stopped |
| 44 | whatever is running in it. Actions jobs keep their own limit: at most 60 |
| 45 | minutes on g1t's machines, or less with `timeout-minutes` (see |
| 46 | [Actions](/guides/actions/)). Your plan can cap a run's time lower still. |
| 47 | |
| 48 | ## Network |
| 49 | |
| 50 | Every sandbox reaches the internet, as a CI machine does: package |
| 51 | registries, GitHub, container registries, your cloud's APIs and anything |
| 52 | else a job or build fetches from or sends to. No setting limits the hosts |
| 53 | a sandbox may reach. |
| 54 | |
| 55 | A sandbox's requests go straight out. Two kinds of request pass g1t's |
| 56 | runner Worker on the way: |
| 57 | |
| 58 | - **A sandbox's report that it stopped itself for mining**, to |
| 59 | `sandbox.g1t.internal`, which never leaves g1t. |
| 60 | - **Every HTTP and HTTPS request of a workflow job that may be given |
| 61 | [brokered secrets](#brokered-secrets)**, so they can be filled in. The |
| 62 | Worker sends each one on, to any host, and tries a download that fails |
| 63 | midway again. To see a request's host and headers over HTTPS, the |
| 64 | connection is re-encrypted with a certificate the sandbox is given when |
| 65 | it starts, which g1t adds to the sandbox's trusted certificates (and |
| 66 | points Node.js, Python, curl, Cargo and git at). The job's other |
| 67 | protocols go straight out. |
| 68 | |
| 69 | The containers a job starts with [Docker](/guides/actions/#docker), its |
| 70 | services and its build steps share the job's network. |
| 71 | |
| 72 | ### Brokered secrets |
| 73 | |
| 74 | The Worker keeps a workflow's API keys out of its jobs. A |
| 75 | [brokered secret](/guides/secrets-and-variables/#brokered-secrets) names |
| 76 | the hosts it is for, and a job is given a stand-in in place of its value. |
| 77 | As a request to one of those hosts passes the runner Worker, the Worker |
| 78 | puts the real value in place of the stand-in, in the request's headers |
| 79 | (inside `Authorization: Basic` too) and its query string, and swaps it |
| 80 | back should the answer echo it. A request to any other host goes with the |
| 81 | stand-in, and the job's log notes it once. The Worker asks for a job's |
| 82 | stand-ins with that job's own token and keeps them only while the job |
| 83 | runs. |
| 84 | |
| 85 | Self-hosted runners' traffic does not pass through g1t, so a runner whose |
| 86 | jobs run on Linux or macOS sends the requests that carry a stand-in to g1t |
| 87 | itself, through a proxy it runs for the job, and g1t fills them in the same |
| 88 | way; see |
| 89 | [on a self-hosted runner](/guides/secrets-and-variables/#on-a-self-hosted-runner). |
| 90 | On Windows, brokered secrets stay stand-ins. |
| 91 | |
| 92 | ## Abuse and mining |
| 93 | |
| 94 | g1t does not run cryptocurrency miners, on any plan. Mining needs hours of |
| 95 | CPU, and g1t's sandboxes watch for it: |
| 96 | |
| 97 | - **Miners by name.** A check, a build command, a workflow step or a container a job starts whose image or |
| 98 | command names a known miner (`xmrig`, `cpuminer`, `t-rex` and others), a |
| 99 | pool address (`stratum+tcp://`) or a miner's flags (`--donate-level`, |
| 100 | `--algo=rx/0`) is refused, whatever the project's rules. A running process whose command line names one stops |
| 101 | the sandbox at once. |
| 102 | - **The CPU signature.** Every sandbox samples itself every 30 seconds: |
| 103 | CPU use, file and disk I/O, network bytes, new processes, and whether the |
| 104 | run did anything (a new check command or workflow step). It is stopped when, for 10 minutes straight, CPU stays at |
| 105 | or above 90% (one dip allowed) while file and disk I/O average under |
| 106 | 64 KB a second, the network under 16 KB a second, fewer than five new |
| 107 | processes start, and nothing else happens. |
| 108 | |
| 109 | Compiling and testing are CPU-bound too, but they read sources, write |
| 110 | objects and start processes (a `cargo build` or `npm test` starts |
| 111 | hundreds), so they do not match. A compiler can spend minutes in code |
| 112 | generation with little I/O, so when the busiest process is a known |
| 113 | compiler or runtime (`rustc`, `cc1`, `clang`, `go`, `javac`, `node` and |
| 114 | others) the sandbox is not stopped for CPU alone. |
| 115 | |
| 116 | A sandbox stopped this way ends with "Stopped: unusual CPU use; contact |
| 117 | support if this was a real job." A check or merge queue run fails with |
| 118 | it, a workflow job fails with it, and a deployment's status says it. g1t's |
| 119 | staff are told, with the measurements, and look at what ran. If it was a |
| 120 | real job, write to support@g1t.sh and say which run. |
| 121 | |
| 122 | Beyond that, what a sandbox may do is bounded by its time cap, your |
| 123 | plan's limits on how much may run and how long, the short-lived |
| 124 | credentials each run is given, and branch protection, which g1t enforces |
| 125 | on every push whatever happened in the sandbox. |
| 126 | |
| 127 | ## What is not covered |
| 128 | |
| 129 | - **Self-hosted runners** run on your machines, and reach whatever those |
| 130 | machines can. See |
| 131 | [self-hosted runners](/guides/self-hosted-runners/#security). |