CI

Where workflows live

Sigbound reads .sigbound/workflows/*.yml and .github/workflows/*.yml. A repository moved from GitHub keeps running its existing workflows. Triggers understood today: push (with branch and path filters) and pull_request, which fires for attempts. Up to twenty workflows run per push.

A first workflow

For a repository with none, this writes one from the tree for Node, Go, Python, Rust or make:

sigbound do starter_workflow org=<space> repo=<repo>

What it returns looks like this:

name: ci
on:
  push:
  pull_request:
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 24 }
      - run: npm ci
      - run: npm run build
      - uses: actions/upload-artifact@v4
        with: { name: dist, path: dist }
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test

What runs, and where

Each job runs in its own sandbox that starts warm, with the runtime and common actions already present; runs-on: ubuntu-latest and ubuntu-24.04 map to it. Jobs, matrices, uses: steps, ::error annotations, timeouts and continue-on-error behave as on GitHub. Secrets come from the repository's Settings → Secrets.

Checks and evidence

Every job reports one check at the attempt's head. Checks are part of the evidence, and a goal's done-means line can be bound to a check by name, so a green job proves the line.

Reuse

When a push produces a tree that has already been verified, its checks are reused and the run reports that it was reused from the earlier attempt. Nothing is re-run for a rebase that changes no bytes.

Artifacts and logs

Files published with actions/upload-artifact@v4 appear under Built artifacts on the evidence, with a download and, for a zip with an index.html, a sandboxed preview. Logs are on the run page and from the terminal:

sigbound ci list
sigbound run logs <run-id>
sigbound do get_ci_log org=<space> repo=<repo> attempt=7.1