fix(cli): carry --file into pipelines started from the TUI

What this MR does and why?

The TUI honors -f/--file when drawing the pipeline graph but not when starting a pipeline, so glci -f custom.yml renders custom.yml and then runs .gitlab-ci.yml. glci show -f and glci run -f are unaffected.

launchTUI reads the flag for parsePipeline but never passes it to the two goroutines that start pipelines, so their requests reach the daemon with an empty ci_file_path and resolveCIFilePath falls back to <workDir>/.gitlab-ci.yml. That fallback is correct protocol, which is why the bug is silent rather than an error.

The fix reads the flag once in launchTUI and threads it into executeTUIRun and handleJobTrigger, which set CIFilePath on their requests.

Two e2e tests cover both TUI paths - the run screen (n) and the job trigger (R). They use a CI file at a non-default path in a project with no .gitlab-ci.yml, because .gitlab-ci.yml is also the daemon's fallback and would make an honored flag indistinguishable from an ignored one. This is the gap that let the bug through: no existing TUI test starts a pipeline, and every one writes its config to the default path. The tests assert on the daemon's parse log, which is emitted before any container work, so they need no Docker.

Steps to reproduce

mkdir -p /tmp/repro/ci && cd /tmp/repro
git init -q && git commit -q --allow-empty -m init

printf 'job-from-root:\n  script: [id]\n'   > .gitlab-ci.yml
printf 'job-from-custom:\n  script: [id]\n' > ci/custom.yml

glci -f ci/custom.yml
# press `n` (new run), then `ctrl+g` (confirm)

Before

The graph shows job-from-custom, the run executes job-from-root, and the daemon logs parsing CI config /tmp/repro/.gitlab-ci.yml.

After

The run executes job-from-custom, and the daemon logs parsing CI config /tmp/repro/ci/custom.yml.

The same applies to r and R on a job in the graph view.

Edited by Paweł Farys

Merge request reports

Loading
Loading