## Summary When a `rules: if:` expression cannot be parsed, glci treats the rule as false and continues. The job disappears from the pipeline and the run exits 0. `glci lint` does not validate expressions either, so nothing catches it beforehand. A folded or literal block scalar — `if: >` or `if: |`, both valid YAML and both commonly used to keep a long condition readable — is one of the expressions glci cannot parse. ## Steps to reproduce Two forms. The first is an obviously invalid expression: ```yaml build: image: alpine:3.20 script: echo build deploy: image: alpine:3.20 script: echo deploy rules: - if: $CI_COMMIT_BRANCH == main # unquoted right-hand side ``` The second is valid YAML that most people would expect to work: ```yaml deploy: script: ./deploy.sh rules: - if: > $CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH == "main" deploy_chomped: script: ./deploy.sh rules: - if: >- $CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH == "main" deploy_literal: script: ./deploy.sh rules: - if: | $CI_COMMIT_BRANCH == "main" ``` Run `glci lint`, then `glci jobs --context branch=main`, then `glci run --context branch=main`. ## Expected behavior `glci lint` reports the invalid expression and exits non-zero. GitLab rejects the first configuration outright and never creates the pipeline. All three block-scalar forms should evaluate normally — GitLab accepts them. ## Actual behavior `glci lint` calls the first configuration valid and exits 0: ``` $ glci lint CI configuration is valid: 2 jobs, 5 stages $ echo $? 0 ``` `glci jobs` prints one warning line to stderr and omits `deploy`: ``` $ glci jobs --context branch=main glci: warning: could not evaluate rule if: "$CI_COMMIT_BRANCH == main": unexpected character 'm' at position 21 JOB STAGE WHEN ALLOW_FAILURE NEEDS build test on_success ``` For the block-scalar configuration, `>` and `|` both fail and only the chomped `>-` form survives: ``` $ glci jobs --context branch=main glci: warning: could not evaluate rule if: "$CI_PIPELINE_SOURCE == \"push\" && $CI_COMMIT_BRANCH == \"main\"\n": unexpected trailing input: "\n" glci: warning: could not evaluate rule if: "$CI_COMMIT_BRANCH == \"main\"\n": unexpected trailing input: "\n" JOB STAGE WHEN ALLOW_FAILURE NEEDS build test on_success deploy_chomped test on_success ``` Changing `>` to `>-` making the difference is what turns this into an arbitrary-looking YAML formatting rule rather than a bug. `glci merged`, added in `caa1ca7`, is the one place the cause is visible. The two failing jobs round-trip as literal block scalars — the trailing newline is still on the string — while the one that works comes back as a plain scalar: ``` $ glci merged -f blocks.yml deploy: rules: - if: | $CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH == "main" script: ./deploy.sh deploy_chomped: rules: - if: $CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH == "main" script: ./deploy.sh deploy_literal: rules: - if: | $CI_COMMIT_BRANCH == "main" script: ./deploy.sh ``` `glci run` is worse than the read-only commands: it prints no warning at all. ``` $ glci run --context branch=main glci: 1 job(s) across 1 stage(s) ... ✓ Pipeline PASSED 4s $ echo $? 0 ``` The warning is emitted inside the daemon process, so it lands in `~/.glci/daemon.log` and never reaches the terminal: ``` glci: warning: could not evaluate rule if: "$CI_COMMIT_BRANCH == main": unexpected character 'm' at position 21 ``` So the one command a user actually runs a pipeline with is the one that says nothing — `deploy` is simply not there, and the pipeline is green. ## Environment - glci `main` at `fb9ba3e` - macOS 15 (darwin 25.5.0), Docker - Affects `glci run`, `glci show`, `glci jobs`, `glci variables`, and `glci lint` (by omission) ## Additional context **An evaluation error becomes `false`.** In `evaluate` in `pkg/rules/evaluator.go`: ```go val, err := evalIf(rule.If, ctx) if err != nil { fmt.Fprintf(os.Stderr, "glci: warning: could not evaluate rule if: %q: %v\n", rule.If, err) matched = false ``` `os.Stderr` is the process's stderr, which is why the line appears for `glci jobs`, `glci show` and `glci variables` — they evaluate in the CLI — and disappears for `glci run`, which evaluates in the daemon. **Why block scalars fail.** `skipWhitespace` in the same file advances past `' '` and `'\t'` only: ```go for p.pos < len(p.input) && (p.input[p.pos] == ' ' || p.input[p.pos] == '\t') { ``` YAML's default clip chomping leaves a trailing `\n` on both `>` and `|` scalars, and `getString` in `pkg/config/merged_yaml.go` — which supplies `If:` when rules are parsed — returns the value unchanged. `evalIf` then reaches its trailing-input check with the newline still in the buffer: ```go p.skipWhitespace() if p.pos < len(p.input) { return false, fmt.Errorf("unexpected trailing input: %q", p.input[p.pos:]) } ``` `cmd/glci/lint.go` contains no rules or expression validation at all — no reference to the `rules` package anywhere in the file. This issue is the amplifier for every other expression-semantics divergence: because an evaluation error becomes `false` rather than an error, a parser bug shows up as a missing job in a green pipeline rather than as a diagnostic. It is the reason `regex-comparison-non-regex-rhs`'s third form is silent. Undisclosed — the "Known limitations" section of the troubleshooting docs does not mention that an unparseable expression is tolerated. ### What the GitLab confirmation still needs ```yaml deploy_unquoted: script: echo hi rules: - if: $CI_COMMIT_BRANCH == main deploy_folded: script: echo hi rules: - if: > $CI_COMMIT_BRANCH == "main" ``` One observable, on a branch named `main`: does GitLab refuse to create the pipeline because of `deploy_unquoted` (expected: yes, `invalid expression syntax`), and — with that job removed — does it create `deploy_folded` and run it (expected: yes)? Reproduced on the glci side against `main` at `fb9ba3e` by running `glci lint`, `glci jobs`, `glci run` and reading `~/.glci/daemon.log`. The same reproductions on `e1f9938`, six commits back, produce byte-identical output — the behaviour is not new. ## GitLab confirmation Confirmed against real GitLab on 2026-08-24, using the project's own CI lint endpoint (`POST /projects/:id/ci/lint` with `dry_run: true`, `include_jobs: true`, `ref: master`) against `vrs-factory/sandbox/glci-sandbox` at `f539929`. That endpoint is GitLab's own pipeline-creation simulation, so it answers both "is this config accepted" and "which jobs would be created" without consuming runner time. **The unquoted right-hand side is a hard error on GitLab.** ```yaml a_unquoted: script: echo A rules: - if: $CI_COMMIT_BRANCH == master ``` ``` .gitlab-ci.yml is invalid. 1 jobs:a_unquoted:rules:rule if invalid expression syntax ``` GitLab refuses the entire configuration — no pipeline is created at all, and the author is told exactly which job and which rule are at fault. glci writes one warning line to stderr, treats the rule as false, drops the job, and exits 0. A whole-pipeline rejection becomes a silently missing job. **The folded block scalar is valid on GitLab and rejected by glci.** ```yaml b_folded: rules: [{ if: ">\n $CI_COMMIT_BRANCH == \"master\"" }] # written as a > block in YAML c_chomped: rules: [{ if: ">-\n $CI_COMMIT_BRANCH == \"master\"" }] # written as a >- block d_quoted: rules: [{ if: '$CI_COMMIT_BRANCH == "master"' }] ``` GitLab reports `valid: True` and creates all three: ``` job b_folded stage=test allow_failure=False when=on_success job c_chomped stage=test allow_failure=False when=on_success job d_quoted stage=test allow_failure=False when=on_success ``` glci creates only `c_chomped` and `d_quoted`. The `>` form carries a trailing newline, which glci's expression parser rejects with `unexpected trailing input: "\n"`, so `b_folded` disappears. GitLab evidently trims the scalar before parsing. This is the sharper half of the defect: `>` and `>-` are interchangeable YAML for a CI author, and choosing the more natural of the two silently loses a job in glci and only in glci.