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
Docs
Status

git agents cloudflare rust forge mcp

syntaqxThe docs' OpenAPI document is current again: b8afae4a changed what the API says of sessions (who sees what, the redaction), and CI #314 stopped at g1t-api's the_docs_copy_is_current. Regenerated with G1T_WRITE_OPENAPI=1. Checked: cargo test --workspace (33 suites, all pass; the desktop app is CI's own job).ea32f46yesterdayHistory

..
.g1tA project can build with a workflow. Turning on **Build with a workflow** under Settings, Deployments installs a managed workflow named `g1t` that calls g1t's reusable deploy workflow (`g1t/workflows/.g1t/workflows/deploy.yml@v1`, published from `workflows/` by the actions release) with the project's settings, and pushes and pull requests then start it rather than a build of Deployments' own: the same previews and production, at the same addresses, reported as `g1t / deploy`, now the check of the workflow's job, listed on the Actions page with its runs and logs. A pull request from a fork runs it with a read-only token, as on GitHub, and still gets its preview without the project's build secrets: a read-only job token may open a preview build only from a run of a managed workflow. Fork pull requests run the repository's managed workflows too. Its jobs are Actions time, at cost plus 20% on g1t's machines and free on a self-hosted runner. A workflow named `g1t` in `.g1t/workflows/` takes its place. The deployments and Actions guides say so.5d ago
README.mdA project can build with a workflow. Turning on **Build with a workflow** under Settings, Deployments installs a managed workflow named `g1t` that calls g1t's reusable deploy workflow (`g1t/workflows/.g1t/workflows/deploy.yml@v1`, published from `workflows/` by the actions release) with the project's settings, and pushes and pull requests then start it rather than a build of Deployments' own: the same previews and production, at the same addresses, reported as `g1t / deploy`, now the check of the workflow's job, listed on the Actions page with its runs and logs. A pull request from a fork runs it with a read-only token, as on GitHub, and still gets its preview without the project's build secrets: a read-only job token may open a preview build only from a run of a managed workflow. Fork pull requests run the repository's managed workflows too. Its jobs are Actions time, at cost plus 20% on g1t's machines and free on a self-hosted runner. A workflow named `g1t` in `.g1t/workflows/` takes its place. The deployments and Actions guides say so.5d ago

..
.g1t
README.md

README.md

g1t/workflows

g1t's own reusable workflows, published from this folder of g1t's repository to g1t/workflows on g1t.sh by .g1t/workflows/actions-release.yml.

Workflow	What it does
`.g1t/workflows/deploy.yml`	Builds the commit onto g1t.page with `g1t/deploy`. The deploy workflow g1t manages for a project calls it.

jobs:
  g1t:
    uses: g1t/workflows/.g1t/workflows/deploy.yml@v1
    with:
      project: web
    secrets: inherit

yaml