Fix gitlab-runner verify failing when CI_SERVER_TOKEN is set

Lachlan Grantrequested to merge
577-verify-ci-server-token-leak into main

Summary

gitlab-runner verify silently used CI_SERVER_URL/CI_SERVER_TOKEN from the process environment as filtering selectors, because VerifyCommand embedded common.RunnerCredentials, whose URL/Token fields are bound to those env vars via env: struct tags. Any unrelated value left in the environment (e.g. injected by a Vault / bank-vaults sidecar, or extraEnvFrom in the Helm chart) that didn't exactly match a configured runner's token caused verify to fail with FATAL: no runner matches the filtering parameters, even though the runner was registered and valid.

This breaks the GitLab Runner Helm chart's liveness probe, which intentionally runs gitlab-runner verify --url= to mean "verify every configured runner, no filtering".

This MR gives verify its own --url/--token flags with no env binding, so only an explicit flag can filter runners - never an inherited environment variable. register/run/unregister keep using CI_SERVER_URL/CI_SERVER_TOKEN from the environment as before; this change is scoped to verify only.

Related: gitlab-org/charts/gitlab-runner#577 (closed)

Test plan

  • Added commands/verify_test.go, covering: no selector verifies all runners; an unrelated CI_SERVER_TOKEN/CI_SERVER_URL in the environment no longer filters runners (regression test for the reported bug); explicit --token / --url+--token still filter to the matching runner.
  • go test ./commands/... passes (aside from a pre-existing, unrelated TestRunnerWrapperCommand_createListener failure that also reproduces on unmodified main in this environment).
  • golangci-lint run ./commands/... reports 0 issues.
  • Manually built the binary before/after the fix and reproduced the exact reported failure on the old binary (CI_SERVER_TOKEN=<unrelated> gitlab-runner verify --url= → FATAL: no runner matches the filtering parameters), confirmed resolved on the new binary.

Merge request reports