Workflow Rules
glci parses and evaluates workflow: during pipeline planning, before any jobs are dispatched. Most workflow: behavior – rules: with if:, variables:, name: – works the same as production GitLab CI. This page covers what is specific to glci.
Context simulation#
The variables available to workflow: rules: depend on the --context you pass:
# Branch context: sets CI_COMMIT_BRANCH, CI_PIPELINE_SOURCE=push
glci run --context branch=main
# Tag context: sets CI_COMMIT_TAG, CI_PIPELINE_SOURCE=push
glci run --context tag=v1.2.3
# Merge request context (default): sets CI_PIPELINE_SOURCE=merge_request_event,
# CI_MERGE_REQUEST_IID, CI_MERGE_REQUEST_SOURCE_BRANCH_NAME, etc.
glci run --context merge_request
# Environment context: sets CI_ENVIRONMENT_NAME
glci run --context env=production
Variables set by context#
| Context | Key variables set |
|---|---|
branch=NAME | CI_COMMIT_BRANCH=NAME, CI_COMMIT_REF_NAME=NAME, CI_PIPELINE_SOURCE=push, CI_DEFAULT_BRANCH=<detected> |
tag=NAME | CI_COMMIT_TAG=NAME, CI_COMMIT_REF_NAME=NAME, CI_PIPELINE_SOURCE=push |
merge_request | CI_PIPELINE_SOURCE=merge_request_event, CI_MERGE_REQUEST_IID=1, CI_MERGE_REQUEST_SOURCE_BRANCH_NAME, CI_MERGE_REQUEST_TARGET_BRANCH_NAME, CI_MERGE_REQUEST_TITLE=local |
env=NAME | CI_ENVIRONMENT_NAME=NAME, CI_PIPELINE_SOURCE=push |
Git-derived variables (CI_COMMIT_SHA, CI_COMMIT_SHORT_SHA, CI_COMMIT_AUTHOR, CI_PROJECT_DIR, etc.) are always available regardless of context.
Testing different contexts#
Use glci show to preview which jobs would run under each context without executing anything:
# Accepted (merge_request context is the default)
glci show
# See what runs for a branch push
glci show --context branch=develop
# See what runs for a tag
glci show --context tag=v1.0.0
Auto-cancel configuration#
workflow: auto_cancel: is parsed for compatibility but has no effect on local pipeline execution, since local pipelines are not triggered by remote push events.
Differences from production GitLab CI#
| Feature | glci | Production GitLab |
|---|---|---|
workflow: rules: changes: | Not evaluated (always matches) | Supported (16.4+) |
workflow: rules: exists: | Not evaluated (always matches) | Supported (16.4+) |
workflow: auto_cancel: | Parsed but not enforced | Actively cancels pipelines |
workflow: name: | Parsed and stored, shown in TUI | Displayed in pipeline UI |
The changes: and exists: clauses in workflow rules are not evaluated because workflow-level evaluation runs before the full filesystem context is available. In job-level rules, both changes: and exists: are fully supported.
All other workflow features – rules: if: expression evaluation, rules: variables:, pipeline rejection on no match – work identically to production.