## Summary The scheduler flattens `needs:` to a list of job names and drops the `optional` flag. A job whose optional dependency is not in the pipeline never becomes ready, and the run ends with the job marked skipped and an exit code of 0. ## Steps to reproduce 1. Create a project with this `.gitlab-ci.yml`: ```yaml stages: [build, test] compile: stage: build image: alpine:3.20 script: echo compile rules: - if: '$COMPILE == "true"' # not set, so this job is excluded unit_tests: stage: test image: alpine:3.20 script: echo tests needs: - job: compile optional: true ``` 2. Run `glci lint`, then `glci run`. ## Expected behavior `compile` is excluded by its rule. Because `unit_tests` declares the need as `optional: true`, GitLab ignores the missing dependency and runs `unit_tests` normally. ## Actual behavior `glci lint` calls the configuration valid. `glci run` runs nothing, marks `unit_tests` skipped, and exits 0: ``` $ glci run --context branch=main glci: 1 job(s) across 1 stage(s) ── stage: test ── ○ unit_tests ⊘ unit_tests (skipped) ────────────────────────────────────────────────── ✓ Pipeline PASSED 1s 1 skipped test ⊘ unit_tests ────────────────────────────────────────────────── $ echo $? 0 ``` Nothing explains why. The word `compile` does not appear anywhere in the output, and neither the terminal nor `~/.glci/daemon.log` carries a diagnostic — the daemon log's last word on the pipeline is `all jobs completed`. Two neighbouring configurations produce the identical green-and-empty result, byte for byte: - the optional dependency does not exist in the YAML at all (`needs: [{job: nonexistent, optional: true}]`); - the dependency is rules-excluded and the need is `optional: false`. The contrast that shows how narrow the hole is: a *plain* missing need is caught properly. ``` $ glci lint # needs: [nonexistent], no optional key CI configuration is invalid: job "unit_tests" needs "nonexistent" which does not exist $ echo $? 2 ``` So validation exists; `optional: true` walks straight past it, and a rules-excluded dependency is invisible to it. ## Environment - glci `main` at `46f1bd3` - macOS 15 (darwin 25.5.0), Docker ## Additional context **The flag never reaches the scheduler.** `NeedRef` in `pkg/config/types.go` carries `Optional bool`, parsed in `pkg/config/merged_yaml.go` as `Optional: getBool(val, "optional", false)`. It is read in exactly two places, both existence checks in the planner: `ValidatePipeline` and its sibling check in the plan builder, both spelled `&& !need.Optional`. `scheduler.New` in `pkg/scheduler/scheduler.go` then throws the struct away: ```go var needs []string for _, n := range job.Needs { needs = append(needs, n.Job) } ``` **The stall.** `depsComplete` requires the need to be in one of two maps: ```go for _, need := range sj.needs { if !s.done[need] && !s.skipped[need] { return false } } ``` A need that is not in the plan is in neither, so the dependent is never ready. `dispatch` recognises the state and gives up quietly — its own comment names it: ```go if len(s.running) == 0 { // Deadlock — nothing running and no ready jobs. // Move remaining pending jobs to skipped so they // are accounted for (e.g. blocked behind manual jobs). ``` `pipelineFailed` is only ever set in `Complete()`, so the executor's `sched.PipelineFailed()` is false and the run is reported as successful. **The `optional: false` route.** `ValidatePipeline` checks against a `jobByName` map built from `pipeline.Jobs`, which contains **all** parsed jobs including rules-excluded ones, so validation passes. The plan builder's `addJob` then drops the excluded upstream on the assumption that the scheduler copes: ```go effective := applyRulesToJob(job) if effective == nil { // Rules evaluated to never — skip, scheduler will handle missing dep return } ``` The scheduler does not handle it; that comment is the bug in one line. Two other routes reach this identical stall-and-report-success path; they are filed separately in #21 because the fix belongs in the planner rather than the scheduler. Undisclosed — `optional:` is not mentioned in the known limitations, and does not appear anywhere in `site/content/`. Reference: [GitLab `needs:` documentation](https://docs.gitlab.com/ci/yaml/needs/). ### What the GitLab confirmation still needs The `compile` / `unit_tests` YAML above, unchanged, on a branch where `COMPILE` is not set. One observable: does GitLab run `unit_tests` (expected: yes — the optional need is ignored), or does it skip it? Reproduced on the glci side against `main` at `fb9ba3e` by running `glci lint` and `glci run` on all three variants. The same reproductions on `e1f9938`, six commits back, produce byte-identical output — the behaviour is not new. ## GitLab confirmation Reproduced on branch `needs-optional-ignored` of `vrs-factory/workshop/glci` at `5add929`, as pipeline [2793675322](https://gitlab.com/vrs-factory/sandbox/glci-sandbox/-/pipelines/2793675322). The earlier check at `f539929` sent the probe YAML in the `ci/lint` request body and committed nothing; this one is a real run against a committed tree. ```yaml compile: stage: build script: echo compile rules: - if: '$COMPILE == "true"' # false, so compile is not created unit_tests: stage: test script: echo unit-ran needs: - job: compile optional: true ``` **GitLab drops the edge and runs `unit_tests`.** The optional need pointed at a job that is not in the pipeline, so the job became immediately runnable and executed: ``` unit_tests stage=test status=success allow_failure=False ``` **glci keeps the edge and then skips the job.** `glci jobs` at `46f1bd3` still lists the dependency: ``` JOB STAGE WHEN ALLOW_FAILURE NEEDS unit_tests test on_success compile ``` and running it produces: ``` ✓ Pipeline PASSED 2s 1 skipped test ⊘ unit_tests ``` with exit code 0. **This is worse than the item originally described.** The consequence is not that the job waits forever — it is that the job GitLab runs is silently skipped, and the pipeline reports success anyway. A test suite guarded by an optional need simply does not execute locally, and nothing in the output says so beyond a `⊘` and a `1 skipped` count that reads like an intentional exclusion. It belongs to the same false-green family as #21.