Load Test & Git
Every load test spec group is tracked as its own Git repository. The Git client built into Atrahasis is the same one you use for flow groups, and the panel just opens against the load-test scope when you trigger it from here.
Per-Spec-Group Repository
Each spec group folder is an independent Git repository with its own history, branches, and remote. One workspace can hold many focused repos, one per API surface, project, or team, instead of a single mega-repo. Each can be connected to a different remote (GitHub, GitLab, internal, anywhere).
- •Scope: Specs, steps, thresholds, per-test-type configs, environments, and lifecycle scripts inside the group are versioned. Auth credentials, OS secrets, and Vault values stay out by design, so only the metadata (key names, references) is tracked.
- •Isolation: A commit in one spec group never touches another. Branching, merging, and rebasing happen inside that group's repo only.
- •Same panel as Flow Runner: The underlying Git panel is identical to the one that handles flow groups. The active scope is the only thing that changes: load test groups are addressed as load-tests/<group-name>, the same shape flow groups use with flows/.
Opening the Git Panel
Right-click any spec group in the Load Test sidebar and pick Git from the context menu (alongside Add Spec / Rename / Environments / Delete). The Git panel takes over the main area and shows the repo state for that spec group.
Alternatively, clone a remote repository directly as a new spec group via the Clone button at the top of the Load Test sidebar. The group is created, every spec inside is wired up, and the Git panel is ready to go.
Why It Matters for Load Tests
- •Version your SLO gates: When thresholds are committed alongside steps, a change to the P95 gate shows up in the diff next to whatever step change it accompanies. No more "who loosened this threshold?" arguments.
- •Branch per scenario: Try an aggressive Stress profile on a branch, run it, compare against the Base run from main, and merge only if it reveals something worth keeping.
- •Team sharing: Push the spec group to a shared remote so teammates clone it and run the same scenarios against the same environments. Combined with the Vault / OS Secret model from Variables & Environments, nothing sensitive is exchanged through git.
- •CI/CD ingestion: A committed spec group is the source of truth the Atrahasis CLI and CI runners consume: pull the group, run the spec, post the report. See the dedicated CI/CD guide section for the runner workflow.
- •Audit trail: History + blame answer "when did this threshold change, and who pushed the new spec?" the same way you would for any source repo.
This page only covers how Git fits into a load-test spec group's lifecycle. The underlying Git client itself, covering the Overview / Changes / History / Branches / Stashes / Settings sections, Setup Wizard, connection types and conflict resolution, is the same one documented in the Flow & Git section and the dedicated Git Integration reference. Everything you learn there applies here verbatim; the only thing that changes is which folder the repo lives in.