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.

syntaqxAsk names people by their g1t username, knows what shipped means, and picks its model by itself. Asked "What shipped today?", Ask made "@chasepierce" out of a commit's git author name, corrected itself mid-answer, and said nothing had reached production though the repository's own Deploy run had: commit listings carried only the git name, the prompt never said which field is a username, and activity counted only g1t.page deployments as production. Commits from list_commits now say `author: { name, username }`, the username from identity's address owners (a confirmed or noreply address; g1t's own are g1t), never the address, and activity's landed commits carry `username` too; the prompt mentions only usernames tools returned, never turns a git name or address into one, and answers once, without "wait" or corrections. Shipping, to Ask, is reaching the default branch and then production: a successful run of a repository's deploy workflow on its default branch (a workflow whose name or file says deploy, not preview) now counts as a production deployment beside g1t.page's, each landed commit says whether it is live (and by which deploy), deploying, failed or not deployed (a deploy carries everything before it on the branch), summary.shipped counts them, and list_runs takes since and until; releases and tags are one more signal, and today is the start of your day in your time zone. Ask's model is Auto by default (migration 0010 turns it on for every Ask route nobody chose a model for: the old picker started on the provider's first model, Haiku for Anthropic). Auto sends each question to a model of the workspace's provider without asking another model: a short lookup to a fast one, a question about why, how, what shipped, changes, failures, a time range, or a long conversation to a standard one; tiers come from the models' names, so it works for every provider, the largest only when nothing else is there, and an Azure deployment or an endpoint without a list keeps its own model. The answer says which ("Anthropic · Auto · claude-sonnet-5-5"); an explicit pick still wins. The Ask guide has Auto and what Ask means by shipped. Checked on this change alone (a worktree of the commit before it): cargo test for g1t-integrations (70, new: Auto's routing for each provider, prompt rules), g1t-api (204, new: commit authors with and without an account, shipped states), g1t-actions-service (108), g1t-contracts (306) and the CLI (149); cargo check --workspace; wasm32 builds of api, integrations and actions; the site's typecheck (tsc -b --force), its Ask tests and a production build; chat's tests and typecheck; the deploy tool's tests.

README.md

g1t/deploy

Builds the checkout a g1t Actions job is in and puts it on g1t.page: production when the run is on the project's production branch, the pull request's preview for a pull request's run, and the branch's preview for a run on any other branch.

name: Deploy

on:
  push:
    branches: [main]
  pull_request:

permissions:
  contents: read
  deployments: write

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - id: deploy
        uses: g1t/deploy@v1
      - run: echo "Live at ${{ steps.deploy.outputs.url }}"
yaml

The project must have Deployments on, and the workspace's plan must include them. The guide, Deploying from a workflow, says what is built and when.

Inputs

InputDefault
projectThe repository's one project with Deployments onThe project's slug. Needed when the repository has several.
root-dirThe project's settingWhere the project is in the checkout.
build-commandThe project's setting, else what the build findsWhat builds it.
output-dirThe project's setting, else the folder the framework writes, else the first of dist, build, out, public, _site, .output/publicThe folder a static build writes.
build-asThe project's setting, else autoWhat it is built as: auto, static, workers or docker. A container is built with the docker on the job's PATH.
dockerfileThe project's setting, else Dockerfile or ContainerfileThe Dockerfile a container is built from, relative to the project.
shaThe run's commitThe commit this is a build of, for its g1t / deploy check.
token${{ github.token }}The job's own token. It needs deployments: write; any other token is refused.

Outputs

Output
urlWhere the app is served.
deployment-idThe build's id, dpl_….
kindproduction or preview.

How it works

  1. It calls POST /repos/{owner}/{repo}/deployments/builds with the job's token. g1t checks the plan and the spend limit, decides production or preview from the run, sets the commit's g1t / deploy check to pending, and answers with a token for this build alone and the project's variables and secrets for builds of that kind.
  2. It masks that token and every secret with ::add-mask::.
  3. It runs g1t-runner deploy in the checkout, which installs, builds and uploads the app exactly as g1t's own builds do, and reports to g1t with the build's token. The build's log is in the step's.

A pull request from a fork or from someone without the Write role, and a run that had to be approved, build without the project's secrets. The build's time is the job's Actions time; it is not charged again.

g1t-runner is on g1t's machines. Elsewhere (a self-hosted runner), the action uses the one on PATH, or downloads the newest release from https://g1t.sh/downloads/runner/latest/ and checks it against the release's SHA256SUMS. It runs on Linux and macOS, with curl and either jq or python3.