gittan.
← Getting started

Your first pipeline

Push code and watch it build. No configuration file needed.

Push and it runs

gittan detects your project type automatically. Push to a repo that contains a package.json, go.mod, or Dockerfile and the pipeline runs immediately — install, lint, test, build — all determined by org policies that match your project files.

You see the result right in your terminal:

$ git push
remote: ── pipeline starting ──────────────────
remote:   feat: add user profile endpoint
remote: ✓ secret-scan          1s
remote: ✓ install              3s
remote: ✓ lint                 4s
remote: ✓ test                 12s
remote: ✓ build                8s
remote: ── pipeline passed ─── 28s ───────────
remote: ✓ main → a1b2c3d

If the pipeline fails, the push is rejected. Fix and push again — no broken code lands on main.

$ git push
remote: ── pipeline starting ──────────────────
remote:   fix: update validation logic
remote: ✓ secret-scan          1s
remote: ✓ install              3s
remote: ✗ test                 9s
remote:   FAIL src/validation.test.ts
remote:     expected 200, received 422
remote: ── pipeline failed ─── 13s ────────────
remote: ✗ push rejected — fix and push again
 ! [remote rejected] main -> main (pre-receive hook declined)

How detection works

There is no magic auto-detection service. Your org’s policies have match rules that check which files exist in the repo. A policy matching package.json provides Node.js steps. One matching go.mod provides Go steps. The pipeline you see is the union of all matching policies.

Three platform policies always run:

  • secret-scan — checks for hardcoded secrets — blocks push if secrets found
  • dep-scan — CVE scanning — blocks push on CRITICAL, advisory on HIGH
  • policy-scan — anti-patterns (SQL injection, :latest tags, etc.) — advisory

Adding .gittan.yaml

Most repos never need a config file. Add .gittan.yaml when you need to:

  • Override the default steps with your own
  • Add a publish step to build and push a container image
  • Add a review gate
  • Declare dependencies on other repos
  • Configure notifications
steps:
  - name: install
    run: pnpm install --frozen-lockfile

  - name: test
    run: pnpm test
    needs: [install]

  - name: build
    run: pnpm build
    needs: [install]

  - name: publish
    publish:
      image: api
    needs: [test, build]

When you add a .gittan.yaml with steps, your steps replace the default policy steps. Enforce policies (like org-wide security scanning) still run — they cannot be overridden.

See the full spec at Pipeline YAML reference.

Gated branches

By default, main is gated — a failing pipeline rejects the push. Other branches run the pipeline but accept the push regardless of the result. Change this with:

gated:
  - main
  - release/*

Viewing runs

Besides the terminal output, you can view pipeline runs in the web UI or CLI:

# Latest run with full output
gittan pipelines logs

# List recent runs
gittan pipelines list --format table

# Specific run
gittan pipelines logs <run-id> --full

What’s next