Execute debugger REPL commands inside job container

[rentziass]

When a job uses a container: definition, the debugger REPL was always executing run commands on the runner host via IProcessInvoker directly. This meant commands like cat /etc/os-release would show the host OS (Ubuntu) instead of the container's OS (e.g. Alpine), making the debugger unreliable for inspecting container job state.

Approach

Instead of duplicating docker exec logic, the REPL executor now reuses IStepHost -- the same abstraction that normal workflow run: steps use. The debugger determines the current step type and creates the appropriate host:

• Action steps (user-defined run:/uses:) get a ContainerStepHost, which routes execution through docker exec (or container hooks when enabled). Script paths and working directories are translated to container paths, and PrependPath is propagated to the container's PATH.
• Infrastructure steps (Set up job, Initialize containers, Stop containers, Complete job) get a DefaultStepHost and always execute on the runner host, since these steps operate outside the container lifecycle.

The guiding principle: running a command in the debug console should behave identically to having a run: step in your workflow file.

Execution context banner

Since DAP doesn't support customizing the console prompt, the debugger now emits a banner each time it pauses at a step so the user knows where commands will run:

Commands will run on job container: alpine:3.20 (a1b2c3d4e5f6)

Commands will run on runner host

Testing

Added unit tests for CreateStepHost covering:

• No container configured -- returns DefaultStepHost
• Container with ID + action step -- returns ContainerStepHost
• Container with ID + infrastructure step -- returns DefaultStepHost
• Container without ID (not yet started) -- falls back to DefaultStepHost

[Copilot]

Pull request overview

This PR updates the DAP debugger REPL so run("...") commands execute in the same place a normal workflow run: step would: inside the job container for user/action steps, and on the runner host for infrastructure steps. It does so by reusing the existing IStepHost abstraction (including container path translation and PATH propagation), and adds a console banner on each pause to indicate where REPL commands will run.

Changes:

• Route REPL execution through IStepHost (container vs host) instead of always using IProcessInvoker directly.
• Add step-type awareness (isActionStep) and emit an execution-context banner on pause.
• Add unit tests for CreateStepHost decision logic.

Show a summary per file

File	Description
src/Runner.Worker/Dap/DapReplExecutor.cs	Switch REPL command execution to IStepHost, handling container path translation and PATH propagation, and add CreateStepHost selection logic.
src/Runner.Worker/Dap/DapDebugger.cs	Pass action/infrastructure step context into the REPL executor and emit a banner indicating host vs container execution.
src/Test/L0/Worker/DapReplExecutorL0.cs	Extend L0 coverage for CreateStepHost across container/no-container and action/infrastructure scenarios.

Copilot's findings

Comments suppressed due to low confidence (1)

src/Runner.Worker/Dap/DapReplExecutor.cs:151

• PrependPath propagation is currently gated on stepHost is ContainerStepHost. Since the step host is created as IContainerStepHost, this will fail to set PrependPath for any non-ContainerStepHost implementation, causing PATH behavior to diverge from normal container step execution. Consider switching this cast/check to IContainerStepHost so all container step hosts receive PrependPath.

                // 7. Handle PrependPath — mirrors Handler.AddPrependPathToEnvironment
                if (context.Global.PrependPath.Count > 0)
                {
                    if (stepHost is ContainerStepHost containerHost)
                    {
                        containerHost.PrependPath = prependPath;
                    }

• Files reviewed: 3/3 changed files
• Comments generated: 3