Load Test & Git
Every load test spec group is tracked as its own Git repository. The Git client built into Tigrister is the same one you use for flow groups — 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 — 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 — for load tests it opens at load-tests/<group-name>.
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 Tigrister 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 — Overview / Changes / History / Branches / Stashes / Settings sections, Setup Wizard, connection types, 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.