Skip to main content

Predefined variables

Every Loom job receives a set of predefined environment variables. This page is the complete reference for what Loom injects, how each variable behaves, and how to map variables when migrating from another CI system.

When to use this page

GoalWhere to look
Writing or debugging a Loom workflow and need the actual values Loom providesLOOM variables and CI compatibility variables below
Migrating from GitLab CI or another system and need to find the Loom equivalentUpstream mapping below
Understanding variable concepts, precedence, and overridesConcepts — Variables

How to read the tables

ColumnMeaning
ScopeWhen the variable becomes available: pipeline (before any job runs), job (when a job starts), or step (when a step executes).
Stabilitystable = contract, safe to depend on. best_effort = populated when context is available, may be empty. placeholder = fixed value today, will gain real semantics later.
SourceWhere the value originates: executor (Loom runtime), provider (host/Docker provider), or workspace (derived from the repo/checkout).

All variables are available in both host and Docker provider environments unless otherwise noted.

LOOM variables

These are Loom-native variables. Prefer these in workflows that only run on Loom.

Pipeline scope

VariableValueStabilitySource
LOOM_CIAlways "true"stableexecutor
LOOM_RUN_IDUnique ID for the loom run invocationstableexecutor
LOOM_PIPELINE_IDPipeline (executor) IDstableexecutor
LOOM_WORKFLOW_PATHPath to the workflow file (empty if not resolvable)stableexecutor

Job scope

VariableValueStabilitySource
LOOM_JOB_NAMEJob name (graph node ID from the workflow)stableexecutor
LOOM_JOB_IDSame as LOOM_JOB_NAMEstableexecutor
LOOM_JOB_STAGEJob stage from the workflow stage: fieldstableexecutor
LOOM_JOB_TARGETJob target (for example linux)stableexecutor
LOOM_JOB_IMAGEDocker image when image: is set; absent otherwisestableexecutor
LOOM_PROVIDERhost or dockerstableexecutor
LOOM_PROJECT_DIRIsolated workspace root where the job runsstableprovider

CI compatibility variables

Loom provides CI_* variables for compatibility with scripts and tools that expect a CI-standard environment. Many mirror a LOOM_* counterpart.

Pipeline scope

VariableValueStabilitySource
CIAlways "true"stableexecutor
CI_RUN_IDSame as LOOM_RUN_IDstableexecutor
CI_PIPELINE_IDPipeline (executor) IDstableexecutor
CI_PIPELINE_IIDSame as CI_PIPELINE_IDstableexecutor
CI_PIPELINE_STARTED_ATRFC 3339 timestamp when the pipeline startedstableexecutor
CI_PIPELINE_STARTED_AT_SLUGURL-safe slug of the started-at timestamp (max 63 bytes)stableexecutor

Job identity

VariableValueStabilitySource
CI_JOB_NAMEJob name (graph node ID)stableexecutor
CI_JOB_IDSame as CI_JOB_NAMEstableexecutor
CI_JOB_STAGEJob stage from the workflow stage: fieldstableexecutor
CI_JOB_TARGETJob target (for example linux)stableexecutor
CI_JOB_IMAGEDocker image when image: is set; absent otherwisestableexecutor

Job runtime

VariableValueStabilitySource
CI_JOB_STATUSAlways "running"stableexecutor
CI_JOB_TIMEOUTAlways "0" (timeout not implemented yet)stableexecutor
CI_JOB_STARTED_ATRFC 3339 timestamp when the job startedstableexecutor
CI_JOB_STARTED_AT_SLUGURL-safe slug of the job started-at timestampstableexecutor

Stage and step

VariableValueStabilitySource
CI_STAGE_STARTED_ATRFC 3339 timestamp when the stage startedstableexecutor
CI_STAGE_STARTED_AT_SLUGURL-safe slug of the stage started-at timestampstableexecutor
CI_STEP_IDAlways "1" (single-shell model today)placeholderexecutor
CI_STEP_STARTED_ATRFC 3339 timestamp when the step startedstableexecutor
CI_STEP_STARTED_AT_SLUGURL-safe slug of the step started-at timestampstableexecutor

Project and directory

VariableValueStabilitySource
CI_BUILDS_DIRTop-level builds/workspaces directorystableprovider
CI_PROJECT_DIRWorkspace root where the job runs (same as LOOM_PROJECT_DIR)stableprovider
CI_PROJECT_NAMEDerived from workspace root directory name (best-effort)best_effortworkspace
CI_PROJECT_NAMESPACESame as CI_PROJECT_NAME todaybest_effortworkspace
CI_PROJECT_NAMESPACE_SLUGURL-safe slug of the namespace (max 63 bytes)best_effortworkspace
CI_PROJECT_NAMESPACE_IDAlways "0"placeholderexecutor

Runner

VariableValueStabilitySource
CI_RUNNER_IDAlways "loom-local"stableexecutor
CI_RUNNER_VERSIONAlways "local"stableexecutor

Git commit

VariableValueStabilitySource
CI_COMMIT_SHAFull HEAD SHA from the workspace snapshotbest_effortworkspace
CI_COMMIT_SHORT_SHAFirst 8 characters of CI_COMMIT_SHAbest_effortworkspace
CI_COMMIT_BRANCHBranch name when resolvable; empty for detached HEADbest_effortworkspace

User-configurable variable

This variable is not injected by Loom but has special runtime behavior when set via workflow variables:.

VariableEffect
CI_DEBUG_TRACESet to "true" to enable verbose shell tracing (set -x). If any secret uses file: false, Loom hard-fails with SECRETS_UNSAFE_DEBUG_TRACE to prevent accidental secret leakage.

Upstream CI → Loom mapping

Use this table when migrating from GitLab CI (or similar systems) and you encounter upstream variable names in existing scripts.

Variables Loom provides

Upstream variableLoom equivalentNotes
CICIBoth set to "true".
CI_COMMIT_SHACI_COMMIT_SHASnapshot HEAD SHA.
CI_COMMIT_SHORT_SHACI_COMMIT_SHORT_SHAFirst 8 characters.
CI_COMMIT_BRANCHCI_COMMIT_BRANCHEmpty when HEAD is detached; prefer LOOM_* where possible.
CI_JOB_NAMECI_JOB_NAME / LOOM_JOB_NAMEPrefer LOOM_JOB_NAME in Loom-only scripts.
CI_JOB_STAGECI_JOB_STAGE / LOOM_JOB_STAGEValues come from the workflow stage: field.
CI_PROJECT_DIRCI_PROJECT_DIR / LOOM_PROJECT_DIRPoints at the isolated workspace root in local runs.
CI_PIPELINE_IDCI_PIPELINE_ID / LOOM_PIPELINE_IDLoom provides both.
CI_JOB_IMAGECI_JOB_IMAGE / LOOM_JOB_IMAGESet only for jobs that use image: (Docker provider).

Variables Loom does not provide

Loom does not derive platform metadata variables (merge requests, actors, URLs, tags). If you need these values, pass them explicitly via workflow or job variables:.

Upstream variableWhat to do instead
CI_MERGE_REQUEST_IIDPass explicitly in variables: from your CI platform or compute in a pre-step.
CI_COMMIT_TAGPass a tag name explicitly, or gate via your own variables.
CI_PROJECT_URLPass explicitly (Loom does not assume your forge remote URL).
CI_COMMIT_AUTHORCompute with git log --format='%an' in a script step, or pass from the outer CI system.
CI_PIPELINE_SOURCENot applicable to local runs. Pass from the outer CI system if needed.

Migration checklist

When porting a workflow from another CI provider to Loom:

  1. Audit variable usage. Search your scripts for $CI_ references and check each one against the mapping table above.
  2. Replace with LOOM_ equivalents where possible. LOOM_* variables are the canonical names and will always be supported.
  3. Pass missing variables explicitly. For any upstream variable without a Loom equivalent, add it to your workflow or job variables: block.
  4. Test with a debug step. Add a temporary step to verify variables are present, then remove it before merging:
script:
- env | grep -E '^CI_|^LOOM_' | sort

Precedence

When a job defines a variables: entry with the same name as a predefined variable, the user-defined value wins. This lets you override any predefined variable for testing or migration purposes. See Concepts — Variables for the full precedence chain.

Freshness and contributions

The variable registry is defined in libs/loom-variables/. If you find a missing or incorrect variable: