AutoMaxProcesses and testing types
Named run recipes with triggers, gates and notifications, and the testing types modules declare.
What a process is, the fields it takes, how the four demo processes differ, how to run one, and which testing types a module can declare.
Testing types
A module declares the kinds of testing it receives. Lint and coverage use the list to spot gaps (a module with visual but no @visual scenario, for example).
| Type | Typical tag | Meaning |
|---|---|---|
functional | @smoke @regression | behaviour of a feature |
smoke | @smoke | fast health checks |
regression | @regression | the full behavioural suite |
sanity | @sanity | narrow checks after a change |
integration | @hybrid | several components or layers together |
contract | @api + schema steps | responses match OpenAPI, JSON Schema or Zod |
visual | @visual | pixel comparison against baselines |
accessibility | @a11y | axe-core violations |
performance | @perf | web-vitals and API latency budgets |
security | @security | authorization and input-handling checks |
data-driven | @data-driven | outlines and datasets |
exploratory | @recorded | recorded sessions before conversion |
Processes
A process is a named run recipe. It captures what a team runs on which occasion so nobody retypes flags.
processes:
- name: pr-check
title: Pull request check
trigger: pr
tags: '@smoke'
browsers: [chromium]
harMode: replay
gates: { minPassRate: 100 }
- name: nightly-regression
title: Nightly regression
trigger: nightly
tags: '@regression'
browsers: [chromium, firefox, webkit]
notify: [github]
- name: release-gate
title: Release gate
trigger: release
tags: '@smoke or @regression'
browsers: [chromium, firefox, webkit]
failOnFlaky: true
gates: { minPassRate: 100, maxFlaky: 0, perfBudgets: true, a11y: true }
- name: api-contract
title: API contract
trigger: merge
layers: [api]
tags: '@contract or @smoke'The workspace file declares the same pr-check, nightly-regression (with schedule: '0 2 * * *') and release-gate under defaults.processes; the project's entries override them by name, so automax processes list -p demo-shop shows four processes.
| Field | Purpose |
|---|---|
trigger | when the process is meant to run: manual, pr, merge, nightly, release, schedule, webhook |
env, tags, layers, browsers, modules | what to select |
workers, retries, harMode, failOnFlaky | how to execute |
gates | conditions that fail the run even when every scenario passed: minimum pass rate, maximum flaky count, performance budgets, accessibility |
notify | integrations to call after the run |
schedule | a cron expression; automax schedule sync turns it into a schedule |
Workspace-level processes under defaults.processes apply to every project; a project process with the same name overrides it.
Run a process
bun run automax processes list -p demo-shop
bun run automax run -p demo-shop --process pr-check
bun run automax run -p demo-shop --process nightly-regression -b chromium # flags override process fields
bun run automax run -p demo-shop --module cart -t @regressionCI workflows call processes by name, so a change of gate or browser list is a YAML edit, not a workflow edit.