Glossary
Terms used in this documentation, in alphabetical order.
Build
One execution of a pipeline. Each push, pull request, or manual run produces one build with live logs, status, timing, and any container images or artifacts it produced. See Builds.
Build id
The unique, stable identifier for a build, the canonical way to refer to one. It appears as the first column of the builds list (shortened, with a copy button), in the build's page title, and in its URL. Share it to point someone at a specific build. A retry gets a new build id. See Builds → Identifying a build.
Job
A named unit of work in .loha.yml. A pipeline can have 1–20 jobs. Jobs run in parallel by default; use needs: to express dependencies. Each job runs in its own isolated environment with its own resource budget. See Pipelines → Jobs.
Pipeline
The sequence of work that runs when a trigger fires, defined in .loha.yml. A pipeline is made of one or more jobs, each containing steps. See Pipelines.
Pipeline-as-Code
Describing your pipeline in a versioned config file (.loha.yml) checked into your repository. Loha is pipeline-as-code only: the dashboard's editor is a convenience layer over the same file; nothing bypasses it.
Plan
Named subscription tiers (e.g. Free, Starter, Professional, Enterprise) are a planned feature: pricing and packaging aren't finalized yet. Today, each workspace's available resource classes, parallel-build cap, log/artifact retention window, and seat limits are governed by a limit preset applied when the workspace is provisioned. See Limits.
Resource class
Pipeline-level compute budget: micro, small, medium, large. Set once at the top of .loha.yml and applied to every job. Available classes depend on your workspace's limit preset. See Pipelines → Resource classes.
Step
The smallest unit of execution in a job. Either a run: shell command or a uses: reference to an official task from the catalog. Steps in a job run sequentially and share the same workspace filesystem.
Trigger
The condition in .loha.yml on: that starts a pipeline run. Supported types: push, pull_request, workflow_dispatch. See Triggers.
Workspace
An isolated environment that owns repositories, secrets, members, and a plan. Workloads in one workspace cannot see or affect those in another. See Workspaces.