## Summary Rule evaluation receives only the pipeline-wide variable map. A job's own `variables:` block and the values injected by `parallel: matrix:` are not in scope, so any rule that tests them sees an empty string and the job is excluded. The variables are otherwise fine — they reach the container and the job prints them. They are invisible to `rules:` specifically, and glci's own rule trace reports the resulting mismatch as a legitimate `false` rather than as a variable it could not see. ## Steps to reproduce ```yaml deploystacks: script: ./deploy.sh parallel: matrix: - PROVIDER: aws SKIP: "false" - PROVIDER: ovh SKIP: "true" rules: - if: '$SKIP == "false"' test: variables: RUN_TESTS: "true" rules: - if: '$RUN_TESTS == "true"' script: make test ``` 1. `glci jobs --context branch=main` 2. `glci variables --context branch=main` 3. `glci run --context branch=main` ## Expected behavior `deploystacks: [aws, false]` is included and `deploystacks: [ovh, true]` is excluded. GitLab documents matrix variables in `rules:if` as a supported way to include or exclude individual matrix jobs. `test` runs, because `RUN_TESTS` is defined on the job. ## Actual behavior Step 1 prints a header and nothing else — all three jobs are gone: ``` JOB STAGE WHEN ALLOW_FAILURE NEEDS ``` Step 2 is the useful one, because it shows the diagnostic contradicting itself in a single screen: ``` deploystacks: [aws, false] (stage: test) [excluded, when: never] Rules: #0 $SKIP () == "false" → false Variables: KEY VALUE SOURCE PROVIDER aws job SKIP false job ``` The `Rules` line expands `$SKIP` to nothing — the empty parentheses are the resolved value — while the `Variables` table two lines below reports `SKIP = false` from source `job`. `deploystacks: [ovh, true]` and `test` render the same way. Step 3 refuses to start: ``` daemon: no jobs to run: 3 jobs parsed but all filtered (rules_excluded=3 never=0 stage_orphaned=0) ``` The variable really is present at runtime; only the rule cannot see it. Give the job a fallback so it survives filtering: ```yaml probe: image: alpine:3.20 variables: RUN_TESTS: "true" rules: - if: '$RUN_TESTS == "true"' - when: always script: echo "RUN_TESTS=[$RUN_TESTS]" ``` `glci run --context branch=main --show-variables` then prints, for the same job, in the same output: ``` Rules: #0 $RUN_TESTS () == "true" → false #1 (always) → true ... RUN_TESTS true job ... [probe] $ echo "RUN_TESTS=[$RUN_TESTS]" [probe] RUN_TESTS=[true] ``` Rule `#0` was evaluated against an empty `RUN_TESTS`, and the container was handed `true`. ## Environment - glci `main` at `46f1bd3` - macOS 15 (darwin 25.5.0), Docker - Reproduced on `glci jobs`, `glci variables`, `glci run` and `glci run --show-variables` ## Additional context `applyFilterWithStats` in `pkg/planner/filter.go` builds the evaluation context from a single pipeline-wide map: ```go r := rules.Evaluate(job.Rules, &rules.EvalContext{ Variables: f.Variables, ... JobWhen: job.When, JobAllowFailure: job.AllowFailure, }) ``` `includeDeps` in `pkg/planner/planner.go` builds the same context from `filter.Variables`. Neither merges `job.Variables` into that map before evaluation, and `EvalContext` has no field for it — the struct carries `JobWhen` and `JobAllowFailure` through from the job, but not its variables. Meanwhile `expandMatrix` in `pkg/config/matrix.go` merges each combination into exactly the field rules never read: ```go // Merge matrix variables into job variables if clone.Variables == nil { clone.Variables = make(map[string]string) } for k, v := range combo { clone.Variables[k] = v } ``` The two halves of the feature do not meet. The omission is repeated on every surface that evaluates rules, which is why the CLI's own debugging tools agree with the wrong answer instead of exposing it. All three pass a job-variable-free map: - `PreparePipeline` in `pkg/daemon/executor.go` builds `allVarsForRules` via `MergeVariables(..., nil, nil)` — the two trailing `nil`s are the `dotenvVars` and `jobVars` parameters — and hands the flattened result to the planner's filter - `evaluateJobRuleTrace` in the same file, which backs `--show-variables`, repeats the identical call - `runVariables` in `cmd/glci/variables.go` builds `ruleVarMap` from `resolveBaseVarLayers`, deliberately "shared with `show`/`jobs` so all three commands resolve identically", and passes it to `resolveJobVariables` The job variables are then added back *after* rule evaluation for the display table and for the container environment, which is precisely why the trace and the table disagree on screen. That is the sharp edge here. #87 asked for variable inspection specifically "to analyze e.g. why some rules did not match", and !123 shipped it. The diagnostic exists, is the documented way to debug this class of problem — `site/content/user-guide/variables.md` calls it "the main way to debug why a rule did or did not match" — and on this bug it points the wrong way. This also interacts with `matrix-job-names-use-sorted-keys`: the shards a user would want to filter are the same ones whose generated names diverge from GitLab's, so selecting the shard by name is not a workaround either. **What the GitLab confirmation still needs** One push, the matrix half only — it covers the job-level half implicitly, since a matrix variable lands in the same `variables:` scope: ```yaml deploystacks: script: echo "$PROVIDER" parallel: matrix: - PROVIDER: aws SKIP: "false" - PROVIDER: ovh SKIP: "true" rules: - if: '$SKIP == "false"' ``` Observable: the created pipeline's job list. One shard (`aws`) present and the other absent confirms GitLab evaluates rules against matrix variables; both absent would mean glci is right and this issue is void. Add a plain job in the same file to separate the two halves cleanly: ```yaml test: variables: RUN_TESTS: "true" rules: - if: '$RUN_TESTS == "true"' script: echo ok ``` Observable: whether `test` is in the pipeline. The Lint API (`dry_run=true&include_jobs=true`) answers both without running anything. Re-ran every step above on `46f1bd3`, on `fb9ba3e` and on `e1f9938`; the observations are identical, so the behaviour is not new. ## GitLab confirmation Reproduced on branch `rules-cannot-see-job-and-matrix-variables` of `vrs-factory/sandbox/glci-sandbox` at `2bb38ab`, as pipeline [2793660843](https://gitlab.com/vrs-factory/sandbox/glci-sandbox/-/pipelines/2793660843). The earlier check at `f539929` sent the probe YAML in the `ci/lint` request body and committed nothing; this one is a real pipeline against a committed tree. Each of the four jobs guards on a variable that is in scope for it — a pipeline variable, the job's own `variables:`, a job variable shadowing a pipeline one of the same name, and a `parallel: matrix:` value. | job | rule tests | GitLab | glci at `46f1bd3` | | --- | --- | --- | --- | | `sees_global` | a pipeline-level variable | created, passed | created | | `sees_job_var` | the job's own `variables:` | **created, passed** | **dropped** | | `job_var_overrides_global` | a job variable shadowing a global of the same name | **created, passed** | **dropped** | | `sees_matrix_var` | a `parallel: matrix:` value | **created as `[a]` only, passed** | **dropped** | GitLab ran four jobs: ``` sees_global stage=test status=success allow_failure=False sees_job_var stage=test status=success allow_failure=False job_var_overrides_global stage=test status=success allow_failure=False sees_matrix_var: [a] stage=test status=success allow_failure=False ``` glci plans one: ``` $ glci jobs --context branch=rules-cannot-see-job-and-matrix-variables JOB STAGE WHEN ALLOW_FAILURE NEEDS sees_global test on_success ``` Three findings, not one: **Job-level `variables:` are visible to that job's own rules.** `sees_job_var` guards on `$JOBVAR == "j"` where `JOBVAR` is declared in the job's own `variables:` block, and GitLab both creates and runs it. **A job variable shadows a pipeline variable during rule evaluation.** `job_var_overrides_global` redeclares `GLOBALVAR` locally and guards on the overridden value; GitLab creates it, so the rule saw the job's value rather than the pipeline's. **Matrix values are visible to rules, and rules are applied per shard.** `sees_matrix_var` declares `TARGET: [a, b]` and guards on `$TARGET == "a"`. GitLab created exactly one job, named `sees_matrix_var: [a]` — it expanded the matrix first, then evaluated the rule against each shard's own value and kept only the matching one. That last point sets the shape of any fix: rule evaluation cannot simply be handed a merged variable map, because for matrix jobs it has to run once per expansion with that expansion's values bound. It also means this item overlaps `matrix-job-names-use-sorted-keys` — both depend on matrix expansion happening before, and feeding into, per-shard evaluation. The count is unchanged since `fb9ba3e`: GitLab creates four jobs, glci creates one.