gitstalk docs actions

GitHub Actions live

Gitstalk runs the .github/workflows/*.yml files you already have, unchanged, on Cloudflare Containers. A repository moved from GitHub keeps its CI and its deploys.

Quickstart

You do not configure anything. Add a workflow the way you would on GitHub, and Gitstalk starts it when your work reaches the stalk.

1. Add a workflow

   Put a normal workflow file in the repository.

   .github/workflows/ci.yml

   name: ci
   on:
     push:
       branches: [main]
     workflow_dispatch:
   jobs:
     test:
       runs-on: ubuntu-latest
       steps:
         - uses: actions/checkout@v4
         - uses: actions/setup-node@v4
           with: { node-version: 24, cache: npm }
         - run: npm ci
         - run: npm test

2. Push it as a bean

   Beans are branches named bean/<name>. The workflow file is part of the change like any other file.

   Terminal

   git push -o wait origin HEAD:refs/heads/bean/add-ci

3. The bean lands, then the stalk moves

   The pre-land check passes and the bean lands on the sprout. When validation promotes the sprout, the stalk moves. On Gitstalk the stalk is your main.

4. The run starts

   A stalk move is a push to main, so ci.yml starts. Open the repository's Automations tab and its Actions view to watch it, or press Run workflow to start it by hand.

[Run npm run build] > api@1.4.0 build
[Run npm run build] compiled 212 modules
[Run npm run build] uploading with token ***

What works today

A small Node job (checkout, setup-node, npm test) took about 20 s end to end on the hosted service with the dependency cache.

When workflows run

Compatibility report

Gitstalk reads each workflow file with GitHub's own parser and expression library. The workflow's page lists what will not run exactly as written, and the Actions view counts the workflows that have notes. Each note says it runs differently (with the difference) or never runs here (with the reason). Everything else runs.

What runs

Job token and OIDC

Each job gets a short-lived token bound to its repository. It is revoked when the job ends and expires on its own shortly after the job's timeout. It can always read the repository.

• permissions: contents: write lets the token push bean/* branches only. Pushes to the sprout, the stalk and main are refused for every credential, so code a job writes still goes through the pre-land check.
• permissions: id-token: write gives the job a GitHub-shaped OIDC identity token from a Gitstalk issuer. Once you register the issuer, actions such as aws-actions/configure-aws-credentials and Google's and Azure's equivalents work. Only stalk, dispatch and schedule runs get one; automation runs never do. A self-hosted deployment gives jobs a token only once its owner has set the OIDC keys.

From an agent

An agent connected over MCP runs the same loop you do. The tools are in the beta tool surface, so check the names against your connected server.

1. Push a bean

   It adds or changes .github/workflows/deploy.yml. When the bean reaches the stalk, the workflow runs.

2. Wait for the run

   actions_wait_for_run with the bean holds until the runs the landing started finish. The default wait is 600 seconds and the most is 1,800. It answers each run's conclusion and, for a failure, the failing step and the last lines of its log.

3. Read the log

   actions_job_log reads more: the newest lines, or only lines matching some text, with secrets already masked.

4. Fix and repeat

   The agent fixes the cause in a new bean, pushes, and waits again.

Setting secrets from an agent is covered in Secrets and variables.

Related pages