Core concepts
The vocabulary used throughout Gitera — organizations, runs, failure clusters, policies, regressions, and deployment workflows.
Account structure
| Term | Meaning |
|---|---|
| Organization | A Gitera workspace mapped to a GitHub organization (or a scope you choose). All data, settings, and members live inside it. |
| Account member | A person invited to the account that owns the organization, with a role that controls access. |
| Repository | A GitHub repository the Gitera app can see inside the connected organization. |
CI/CD entities
| Term | Meaning |
|---|---|
| Workflow | A YAML file under .github/workflows/ in a repository. |
| Workflow run | One execution of a workflow (triggered by push, PR, schedule, or manual dispatch). |
| Job / Step | A run is made of jobs; each job runs steps on a runner. Gitera tracks durations and logs at step level. |
| Runner | The machine executing a job: GitHub-hosted (ubuntu, windows, macos) or self-hosted. |
| Queued job | A job waiting for an available runner — long queue times usually mean runner starvation. |
Gitera-specific concepts
| Term | Meaning |
|---|---|
| Workflow group | A named tag you assign to workflows to filter the dashboard (e.g. "deploy-prod"). |
| Failure cluster | Several runs failing with the same error signature, grouped into one incident you can triage and document. |
| Policy | An organization-wide rule checked against workflow files (e.g. "all jobs must set a timeout"). |
| Regression | A statistically significant slowdown or cost spike in a workflow versus its recent baseline. |
| Deployment workflow | A workflow you flag as deploying to production — the input for DORA metrics. |
| Auto-retry rule | A guardrailed rule that re-runs the failed jobs of a run, scoped by repository, workflow, branch, and job name. |