Skip to content
⌘K
Explore
Download
Docs
Sign in
Sign up
flagon-io
/
g1t
public
Star
0
Overview
Code
Issues
Pull requests
Workflows
Deployments
Insights
Files
Commits
Branches
Tags
Releases
Compare
e2b3c4d94d54ab9dee56d6f432f479aaa92c3697
g1t
/
…
/
services
/
actions
/
src
syntaqx
The Branches page updates live too: a branch pushed, created, renamed or deleted shows while you are on it, and the notifications guide lists it among the pages that do.
e2b3c4d
yesterday
History
..
cache.rs
lib.rs
managed.rs
mirrored.rs
payload.rs
plan.rs
protection.rs
reach.rs
registry.rs
rename.rs
run_artifacts.rs
runners.rs
runtime.rs
settings.rs
sync.rs
trigger.rs
views.rs
..
cache.rs
Merge remote-tracking branch 'origin/main' into workspace-chat
4d ago
lib.rs
Merge branch 'worktree-agent-a5c94df323642630e'
yesterday
managed.rs
A 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.
yesterday
mirrored.rs
Merge branch 'mirroring' into artifacts-mode
4d ago
payload.rs
Merge remote-tracking branch 'origin/claude/cool-newton-7nm8r9'
yesterday
plan.rs
Merge branch 'worktree-agent-a5c94df323642630e'
yesterday
protection.rs
Merge branch 'worktree-agent-a8b78c62188153aa3' into claude/cool-newton-7nm8r9
yesterday
reach.rs
Merge remote-tracking branch 'origin/claude/cool-newton-7nm8r9'
yesterday
registry.rs
A workflow's `uses: actions/setup-node@v4` means GitHub's `actions` again, whoever is on g1t. g1t looked for a repository on g1t before GitHub, and anyone could make a public workspace called `actions`, `docker` or `aws-actions` and have its `setup-node` run in every workflow that names GitHub's, with that job's secrets. Now another workspace's public repository answers only for a name GitHub has no public repository of; the caller's own workspace and g1t's own `g1t/…` still answer from g1t, and when GitHub can't be asked, GitHub's is used. The names of the GitHub accounts whose actions workflows use most can no longer be registered, renamed to, or taken by signing up with GitHub (which suggests the name with `-gh`); an account that has one keeps it, and mentions and invitations still find it. The Actions, authentication and workspaces guides say so.
yesterday
rename.rs
Merge Actions runs: summaries, attempts and re-runs, graceful cancel, log downloads, badges (actions 0009)
5d ago
run_artifacts.rs
The artifacts service is services/artifacts, the Worker g1t-artifacts, bound as ARTIFACTS by the API, the site and the agents; its live rooms move to it with a Durable Object transfer from g1t-docs-service, and its database, bucket, indexes and queue keep their names. The git store's binding and settings are GITSTORE, its ops scripts gitstore-*, and workflow run artifacts keep their compatible API under run_artifacts modules. The deploy tool puts a Worker that has never deployed before the Workers in its stage that bind to it, and the deploy guide gives the cutover runbook.
3d ago
runners.rs
Merge branch 'worktree-agent-ac79a505eca749d4d' into claude/cool-newton-7nm8r9
yesterday
runtime.rs
Merge branch 'worktree-agent-af75396ad4c6ee7a8' into claude/cool-newton-7nm8r9
yesterday
settings.rs
Merge branch 'worktree-agent-a3abfcce648e87dca'
5d ago
sync.rs
A repository can run a managed workflow: one installed by g1t's own services without a file in the repository. It is listed, started, run and re-run like any workflow in `.g1t/workflows/`, under the path `managed/<name>.yml`, and a workflow of the same `name:` in the repository runs in its place, so moving one into the repository is committing its source. The Actions page says a managed workflow is managed by g1t rather than linking to a file. Nothing installs one yet; the deploy workflow deployments will install, which calls g1t's reusable deploy workflow with a project's settings as its inputs and reports as `g1t / deploy`, is written and tested but not installed.
yesterday
trigger.rs
Merge remote-tracking branch 'origin/claude/cool-newton-7nm8r9'
yesterday
views.rs
A run opens on its summary: what triggered it, its status, duration and artifacts, a graph of its jobs (what needs what, matrices folded, called workflows boxed, deploys with their address), annotations, and each job's summary; the job list groups the same way
4d ago
