## Summary glci parses the `workflow:` block and stores it, but nothing ever evaluates it. A pipeline that GitLab would refuse to create runs locally and reports success, and `workflow: rules: variables:` never reach any job even when the rule matches. The documentation states the opposite in three places. ## Steps to reproduce 1. Create a project with this `.gitlab-ci.yml`: ```yaml workflow: rules: - if: $CI_PIPELINE_SOURCE == "schedule" variables: DEPLOY_ENV: nightly - when: never build: image: alpine:3.20 script: - echo "DEPLOY_ENV=[$DEPLOY_ENV]" ``` 2. `glci jobs --context branch=main` 3. `glci run --context branch=main` 4. Change the first rule's condition to `$CI_PIPELINE_SOURCE == "push"` so it *does* match under `--context branch=main`, drop the `- when: never`, and run `glci variables build --all --context branch=main`. ## Expected behavior At steps 2 and 3 the first rule does not match — `--context branch=main` sets `CI_PIPELINE_SOURCE=push`, not `schedule` — and the second rule is `when: never`, so no pipeline is created. GitLab reports "pipeline filtered out by workflow rules" and creates nothing. At step 4 the matched rule's `variables:` block is in scope for every job in the pipeline, so `DEPLOY_ENV` resolves to `nightly`. ## Actual behavior Step 2 plans the job as if the `workflow:` block were absent: ``` JOB STAGE WHEN ALLOW_FAILURE NEEDS build test on_success ``` `glci merged`, which prints the fully-resolved configuration, carries the block straight through: ```yaml build: image: alpine:3.20 script: - echo "DEPLOY_ENV=[$DEPLOY_ENV]" workflow: rules: - if: $CI_PIPELINE_SOURCE == "schedule" variables: DEPLOY_ENV: nightly - when: never ``` Parsed, preserved, and acted on by nothing. Step 3 runs it and reports success, exit code `0`: ``` [build] $ echo "DEPLOY_ENV=[$DEPLOY_ENV]" [build] DEPLOY_ENV=[] ✓ Pipeline PASSED 4s 1 passed ``` Step 4 shows the other half. With the rule matching, `glci variables build --all` lists 28 rows, every one of them attributed to `predefined` or `predefined:job`. `DEPLOY_ENV` does not appear at any source. A workflow block reduced to a single rule that cannot match, `- if: '$NEVER_SET == "yes"'` with no other entries, also plans and runs `build` normally. So `workflow: rules:` never rejects a pipeline under any condition, and `workflow: rules: variables:` never reach a job even when the rule matches. ## Environment - glci `main` at `46f1bd3` - macOS 15 (darwin 25.5.0), Docker - Any CI config with a `workflow:` block ## Additional context `EvaluateWorkflowRules` in `pkg/config/workflow.go` has zero callers outside its own test file — grepping the name across the repo returns only `pkg/config/workflow_test.go`. The function is implemented and tested; nothing invokes it. `ParseOffline` in `pkg/config/offline_parser.go` calls `ParseWorkflow` and assigns the result to `pipeline.Workflow`. The only code that reads that field afterwards is `pkg/tui/app.go`, which copies the pointer into a filtered pipeline struct in two places and never renders it — those two assignments are the sole occurrences of `Workflow` in all of `pkg/tui/`. That also disposes of the `name:` row in the docs table below, which claims `workflow: name:` is "shown in TUI": nothing in the TUI reads `Workflow.Name`. `ParseOfflineOptions.IfEval` exists specifically to let a caller supply the expression evaluator and break the import cycle with `pkg/rules`: ```go // IfEval evaluates rules: if: expressions for workflow rules. IfEval IfEvaluator ``` `ParseOffline` never reads it, and no caller anywhere sets it — the `offlineOptions` method on `ParsePipelineOptions` in `pkg/config/pipeline_parser.go` forwards `o.IfEval` into the struct and that is the end of the chain. There is no alternative evaluation path: `cmd/glci/` contains no occurrence of "workflow" at all. What the documentation claims: - `site/content/user-guide/workflow-rules.md`, opening line — "glci parses and evaluates `workflow:` during pipeline planning, before any jobs are dispatched." - the same page, closing the "Differences from production GitLab CI" section — "All other workflow features -- `rules: if:` expression evaluation, `rules: variables:`, pipeline rejection on no match -- work identically to production." - `site/content/architecture/how-it-works.md`, step 2 of the run sequence — the offline parser "evaluates workflow/job rules". The differences table on that page lists only `changes:`, `exists:`, `auto_cancel:` and `name:` as diverging, which implicitly asserts that `if:`, `variables:` and rejection work. Its `exists:` row — "Not evaluated (always matches)" — is the closest the docs come to the truth, and it understates it: no workflow rule clause is evaluated, not just that one. Related: closed umbrella issue #14 audited every keyword glci parses without enforcing, and never mentions `workflow:` at any level — not `rules:`, not `name:`, not `auto_cancel:`. The gap has not been recorded upstream before. **What the GitLab confirmation still needs** Only the rejection half genuinely needs GitLab; the variables half is already a glci-side contradiction with its own documentation. Push this to any branch: ```yaml workflow: rules: - if: $CI_PIPELINE_SOURCE == "schedule" - when: never build: script: echo ok ``` Observable: whether a pipeline is created at all. GitLab should reject the push with "pipeline filtered out by workflow rules" and show no pipeline; glci runs `build` and exits 0. For the variables half, if it is worth one extra confirmation: ```yaml workflow: rules: - if: $CI_PIPELINE_SOURCE == "push" variables: DEPLOY_ENV: nightly build: script: echo "DEPLOY_ENV=[$DEPLOY_ENV]" ``` Observable: the job log line — `nightly` on GitLab against the empty value glci prints. Re-ran every step above on `46f1bd3`, on `fb9ba3e` and on `e1f9938`; the observations are identical, so the behaviour is not new. The one thing that moved between them is the `IfEval` forwarding, which was lifted out of `parseOfflineWithOpts` into the new `offlineOptions` method — it is still forwarded and still never read. ## GitLab confirmation Reproduced on branch `workflow-rules-never-evaluated` of `vrs-factory/sandbox/glci-sandbox` at `e571165`, which carries both halves as committed files. The earlier check at `f539929` sent the probe YAML in the `ci/lint` request body and committed nothing. **GitLab refuses to create the pipeline; glci runs it and reports success.** `blocked.gitlab-ci.yml` on the branch: ```yaml workflow: rules: - if: '$CI_COMMIT_BRANCH == "a-branch-that-does-not-exist"' build: script: echo should-not-run ``` That file was pushed as `.gitlab-ci.yml` in the parent commit `d19e77f`, and GitLab created **nothing** — `GET /projects/:id/pipelines?ref=workflow-rules-never-evaluated` returned `[]` after a successful push. `POST /ci/lint` names the reason: ``` valid: False error: The pipeline did not run. Review the workflow:rules configuration for the pipeline. ``` glci at `46f1bd3` runs it: ``` $ glci run --context branch=workflow-rules-never-evaluated ✓ build (2.2s) ✓ Pipeline PASSED 5s 1 passed ``` It is not that a job is missing — an entire pipeline GitLab would never have created executes locally and passes. A `workflow:` block written to confine a pipeline to certain branches, tags or pipeline sources has no effect in glci, and the green result actively suggests the guard was satisfied. **`workflow: rules: variables:` never reach the job either.** `.gitlab-ci.yml` on the same branch sets a variable from the matching workflow rule: ```yaml workflow: rules: - if: '$CI_COMMIT_BRANCH == "workflow-rules-never-evaluated"' variables: WF: "from-workflow-rule" - when: always show: script: echo "WF=[$WF]" ``` Pipeline [2793665123](https://gitlab.com/vrs-factory/sandbox/glci-sandbox/-/pipelines/2793665123), job `show`: ``` $ echo "WF=[$WF]" WF=[from-workflow-rule] ``` glci at `46f1bd3`, same file: ``` $ echo "WF=[$WF]" WF=[] ``` So the block is parsed and then ignored in both directions: it gates nothing, and the variables it carries never bind. This remains the widest divergence in the batch. It also undermines local verification generally — the class of mistake `workflow:` exists to catch, a pipeline running on the wrong ref or for the wrong `CI_PIPELINE_SOURCE`, is precisely the class glci cannot reproduce today.