## Summary When `FF_SCRIPT_TO_STEP_MIGRATION` is enabled, the runner-internal environment variable `CONFIG_FILE` leaks into user scripts executed via the step-runner. This causes user binaries that happen to read `CONFIG_FILE` from the environment (e.g. via `urfave/cli` env var bindings) to receive the runner's default config path (`/etc/gitlab-runner/config.toml`), which doesn't exist inside the build container, leading to job failures. ## Root Cause The leak happens through this chain: 1. **`commands/config.go:18-26`** — An `init()` function unconditionally calls `os.Setenv("CONFIG_FILE", GetDefaultConfigFile())` (resolving to `/etc/gitlab-runner/config.toml`) if `CONFIG_FILE` is not already set in the process environment. 2. **Helper binary transitively imports `commands`** — `apps/gitlab-runner-helper/main.go` imports `commands/helpers`, which imports `commands`, triggering the `init()`. This sets `CONFIG_FILE=/etc/gitlab-runner/config.toml` in the helper's process environment. 3. **In step mode, the helper binary IS the container's main process** — The Docker executor starts the build container with `CMD [helper, "steps", "serve", ...]`. The step-runner runs inside this process. 4. **`commands/steps/steps.go:142-145`** — The `Serve()` function creates a DI container which calls `runner.NewEnvironmentFromOS()` (step-runner `di/container.go:154`). This reads ALL OS environment variables from the helper process, including the leaked `CONFIG_FILE`. 5. **`functions/script_legacy/script_legacy.go:149-155`** — When executing user scripts, `builtinCtx.GetEnvList()` returns the full environment (including `CONFIG_FILE`), and job variables are appended. The combined env is passed to `cmd.Env`, making `CONFIG_FILE` visible to user commands. 6. **User binary fails** — Any user binary that reads `CONFIG_FILE` from the environment receives `/etc/gitlab-runner/config.toml`, tries to access the file, and fails because it doesn't exist in the build container. ## Why This Doesn't Happen in Traditional Mode In traditional (non-step) mode, the Docker container is created with `config.Env = jobVars.StringList()` — only CI/CD job variables. `CONFIG_FILE` is a runner-internal process variable, not a CI variable, so it never enters the container's environment. User scripts only see CI variables plus image defaults. In step mode, `config.Env = nil` (the container starts with only image defaults). But the helper binary running inside the container has `CONFIG_FILE` in its own process env from the `init()`, and `NewEnvironmentFromOS()` picks it up. ## Reproduction Any CI job with `FF_SCRIPT_TO_STEP_MIGRATION: true` that runs a binary sensitive to the `CONFIG_FILE` environment variable will fail. Example: ```yaml job: image: golang:1.26 variables: FF_SCRIPT_TO_STEP_MIGRATION: "true" script: - echo $CONFIG_FILE # Will print /etc/gitlab-runner/config.toml - ./my-binary # May fail if it reads CONFIG_FILE ``` Observed in the `oncall-robot-assistant` project where the binary uses `urfave/cli` with `EnvVars: []string{"CONFIG_FILE", "CONFIG"}`. ## Fix Options 1. **Clear `CONFIG_FILE` before creating the step-runner service** — In `commands/steps/steps.go` `Serve()`, call `os.Unsetenv("CONFIG_FILE")` before `di.NewContainer()`. Targeted fix with minimal blast radius. 2. **Guard the `init()` in `commands/config.go`** — Only set `CONFIG_FILE` when running as the main runner process, not when running as the helper. More thorough but riskier since other code paths may depend on it. 3. **Filter runner-internal variables in step-runner's environment** — Add `CONFIG_FILE` (and potentially other runner-internal vars) to a rejection list in `NewEnvironmentFromOS()`. This would be a step-runner change. 4. **Use `NewEnvironmentFromOSWithKnownVars()` in the serve path** — The step-runner already has a function that only passes through well-known system variables (PATH, HOME, LANG, etc.). However, this might be too restrictive and filter out legitimate image ENV variables users need. ## Potentially Affected Variables The same `init()` pattern should be audited for other variables that might leak. `CONFIG_FILE` is the known case, but any `os.Setenv` in `init()` functions of transitively imported packages could have the same effect. ## Related - Step-runner work item: https://gitlab.com/gitlab-org/step-runner/-/work_items/319 (referenced in oncall-robot-assistant CI config as a workaround)