Workflows
Declarative YAML files that define what runs on each push.
Workflows define what happens when you push to a gate repo. They live in .airlock/workflows/*.yml in your repo.
Workflow File
A workflow is a YAML file with a name, trigger, and one or more jobs. The default pipeline uses parallel jobs:
Wave 1: [rebase]
Wave 2: [critique] [test] ← parallel
Wave 3: [gate] ← conditionally pauses for approval
Wave 4: [describe] [document] ← parallel
Wave 5: [lint → push → create-pr] ← sequential deployname: Main Pipeline
on:
push:
branches: ['**']
jobs:
rebase:
name: Rebase
steps:
- name: rebase
uses: airlock-hq/airlock/defaults/rebase@main
critique:
name: Critique
needs: rebase
steps:
- name: critique
uses: airlock-hq/airlock/defaults/critique@main
test:
name: Test
needs: rebase
steps:
- name: test
uses: airlock-hq/airlock/defaults/test@main
gate:
name: Review Gate
needs: [critique, test]
steps:
- name: review
uses: airlock-hq/airlock/defaults/gate@main
env:
# Change to never, low, medium, or high to control when human approval is required.
AIRLOCK_RISK_THRESHOLD: medium
deploy:
name: Lint & Push
needs: [describe, document]
steps:
- name: lint
uses: airlock-hq/airlock/defaults/lint@main
apply-patch: true
- name: push
uses: airlock-hq/airlock/defaults/push@main
- name: create-pr
uses: airlock-hq/airlock/defaults/create-pr@mainTop-Level Properties
| Property | Description |
|---|---|
name | Human-readable name for the workflow |
on.push.branches | Glob patterns for branch filtering (e.g., ['main', 'feature/**']) |
jobs | Map of job keys to job definitions |
Jobs
Each job has a name and a list of steps. Steps within a job run sequentially. Multiple jobs can run in parallel using the needs keyword to declare dependencies.
jobs:
lint:
name: Lint
steps:
- name: lint
uses: airlock-hq/airlock/defaults/lint@main
test:
name: Test
needs: [lint]
steps:
- name: test
uses: airlock-hq/airlock/defaults/test@mainIn this example, test waits for lint to complete before starting.
Steps
Each step either runs a shell command (run) or references a reusable step definition (uses) — from a Git repository (owner/repo/path@ref) or a local directory (./path). Steps also support options like shell, continue-on-error, require-approval, and apply-patch. See the Workflow YAML Schema for all step properties.
Note the kebab-case format: continue-on-error, require-approval, and apply-patch, not snake_case.
Branch Filtering
The on.push.branches field accepts glob patterns to control which branches trigger the workflow. See the Workflow YAML Schema for supported patterns.
If a push doesn't match any workflow's branch patterns, Airlock forwards it to upstream directly — no workflow runs, no Push Request is created.
Related
- Custom Workflows — Build your own workflow from scratch
- Freeze — How the freeze step divides your workflow
- Workflow YAML Schema — Full schema reference