Skip to content

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

Commit

The architecture pages describe main (#52): the merge queue builds and lands each entry by its own merge method in the repository itself, so Work and the merge queue no longer says a sandbox merges each candidate, a merge lands by the method asked for rather than as the head, and Actions, runners and sandboxes drops the queue mode from the work that runs in sandboxes (queue_build returns no jobs since b5c43d31) and says only merge_group workflow runs use one. Workflows are read from .g1t/workflows at the commit an event is about, never .github/workflows (sync.rs reads one folder). Services and contracts calls what integrations holds the workspace's AI providers and Ask, and Identity names billing and security managers as the roles that add to a member, not organisation roles.

Checked:
services/work/src/queue.rs (queue_build returns Vec::new()), services/repos/src/merge_methods.rs, services/actions/src/sync.rs (read_workflows reads FOLDER only), services/integrations/src/ai.rs; npm test in apps/docs (4) and npm run test:deploy (92) pass; the docs build.
G1t-Session:
ses_01m4ynr1peevvs8zwaqakycv2e
syntaqxcommitted Parent1f0286eBrowse files
4 files+22−140/4 viewed
+12−6
77 import Diagram from '../../../components/Diagram.astro';
88
99 Everything that runs code you did not write runs in a sandbox: workflow
10−jobs, merge queue builds, deployments, dependency updates, backups. Three
11−pieces share the work.
10+jobs, merge checks, deployments, dependency updates, backups. Three pieces
11+share the work.
1212
1313 | Piece | Is | Does |
1414 | --- | --- | --- |
2626 <Diagram name="actions-job" />
2727
2828 1. **Trigger.** `actions` reads its event queue, `g1t-events-actions`, ten
29− at a time (step 1), and matches each event to the workflows read from
30− the default branch's `.g1t/workflows` (or `.github/workflows`). The
31− files are GitHub Actions syntax, unchanged; [GitHub
29+ at a time (step 1), and matches each event to the workflows in
30+ `.g1t/workflows` at the commit the event is about (the default branch
31+ for schedules, issues and manual runs; `services/actions/src/sync.rs`).
32+ g1t never reads `.github/workflows`. The files are GitHub Actions
33+ syntax, unchanged; [GitHub
3234 Actions](/guides/actions/) lists what is supported.
3335 2. **Plan.** It expands matrices, orders jobs by `needs`, and reports the
3436 run as pending on the commit (steps 2 and 3).
148150 | Mode | Started by | Does |
149151 | --- | --- | --- |
150152 | `actions` | `actions` | A workflow job |
151−| `queue` | `runner`, when the queue changes | Builds a merge queue candidate |
152153 | `mergecheck` | `runner`, when a pull request changes | Checks whether a pull request merges cleanly |
153154 | `deploy` | `deployments` | Builds an app ([Deployments](/architecture/deployments/)) |
154155 | `bump` | `security` | Makes a dependency update |
155156 | `backup` | `runner`'s sweep, every 5 minutes | Cuts a repository backup ([Git](/architecture/git/#backups)) |
156157
158+The merge queue needs no sandbox of its own: `work` builds each queued
159+state in the repository itself ([Work](/architecture/work/#the-merge-queue)),
160+and only the workflows that run on `merge_group` run in sandboxes, as
161+workflow jobs.
162+
157163 Compute is admitted through billing: a sandbox starts only after
158164 `billing` holds its estimated cost (`reserve`), and the hold is settled
159165 with the real cost when it ends (`settle`).
+2−2
3939 | Field | Holds |
4040 | --- | --- |
4141 | `kind` | `User`, `Workspace`, `Agent` or `System`: what kind of principal this is |
42−| `workspaces` | Each membership: the role, the workspace's base permission, organisation roles such as billing or security manager, and privileges |
42+| `workspaces` | Each membership: the role, the workspace's base permission, the roles that add to a member, such as billing or security manager, and privileges |
4343 | `grants` | Roles on repositories, directly or through teams |
4444 | `acting` | For a job or run token: the narrower scope it acts within |
4545
6363
6464 | Level | Roles |
6565 | --- | --- |
66−| Workspace | Owner and member, plus organisation roles (billing manager, security manager) and member privileges |
66+| Workspace | Owner and member, plus the roles that add to a member (billing manager, security manager) and member privileges |
6767 | Repository | Read, Triage, Write, Maintain and Admin, given to a person, a team, or everyone in the workspace as its base permission |
6868 | Outside collaborators | A repository role for someone who is not a member |
6969
+1−1
3838 | `services/notify` | TypeScript | core | Notifications, live pages, presence, browser and phone push | A Durable Object per person, per workspace and per repository | `identity` |
3939 | `services/telemetry` | TypeScript | core | Logs, traces, metrics and errors for projects, at `otel.g1t.sh` | A Durable Object per project | `billing` |
4040 | `services/billing` | Rust | core | Usage, holds and settlements, limits, Stripe | D1 `g1t-billing` | `identity`, `packages`, `repos` |
41−| `services/integrations` | Rust | core | Model providers, alert sources, issue trackers, the GitHub App, Ask g1t | D1 `g1t-integrations` | `identity`, `projects`, `repos`, `work` |
41+| `services/integrations` | Rust | core | The workspace's AI providers and Ask g1t, alert sources, issue trackers, the GitHub App | D1 `g1t-integrations` | `identity`, `projects`, `repos`, `work` |
4242 | `services/webhooks` | Rust | core | Webhook subscriptions and signed deliveries with retries | D1 `g1t-webhooks` | `identity`, `repos` |
4343 | `services/og` | TypeScript | core | Social cards and page screenshots, at `og.g1t.sh` | The screenshots bucket | `billing`, `identity`, `projects`, `repos`, `work` |
4444
+7−5
9595 and whether the person asking may bypass it. A merge happens only when
9696 none fails or waits, for people and coding agents alike.
9797
98−When everything passes, `work` asks `repos` to land the pull request's
99−head on the base, and publishes `pull.merged`.
98+When everything passes, `work` asks `repos` to land the pull request on
99+the base by the merge method asked for: a merge commit, squash, rebase or
100+fast-forward (`services/repos/src/merge_methods.rs`). Then it publishes
101+`pull.merged`.
100102
101103 ## The merge queue
102104
108110 <Diagram name="merge-queue" />
109111
110112 1. **Build.** Up to `max_entries_to_build` entries (4 by default) are
111− tested at once. For each, a sandbox merges the default branch with that
112− entry and every entry ahead of it, and pushes the result to
113− `g1t-queue/<entry>` in the repository.
113+ tested at once. Each entry is landed by its own merge method on the
114+ state of the entry ahead of it (the default branch, for the first), and
115+ the result is pushed to `g1t-queue/<entry>` in the repository.
114116 2. **Test.** Workflows that run on `merge_group` run on each of those
115117 commits, and the required checks have to pass there.
116118 3. **Land.** Entries land in order. Once everything ahead of it has landed,

Comments

Sign in to comment.