fix: propagate RunnerConfig to detection job to fix arc-dind Copilot ENOENT

[Copilot]

On arc-dind runners, the threat-detection job silently no-ops: AWF spawns /usr/local/bin/copilot inside the chroot (which runs on the dind daemon's filesystem where that path doesn't exist), gets ENOENT, and the continue-on-error: true on the execution step swallows the failure — detection appears green while never running.

Root cause

buildDetectionEngineExecutionStep constructs a fresh threatDetectionData without copying RunnerConfig from the parent data. This makes isArcDindTopology(threatDetectionData) always false, so two arc-dind behaviors are skipped for detection only:

1. Staging step — nodejs.go: the "Copy Copilot CLI to daemon-visible path" step is gated on isFirewallEnabled && isArcDindTopology → not emitted
2. Spawn path — copilot_engine_execution.go: resolveCopilotCommand falls through to constants.CopilotBinaryPath (/usr/local/bin/copilot) instead of ${RUNNER_TEMP}/gh-aw/bin/copilot

Fix

One-line change in threat_detection_inline_engine.go:

threatDetectionData := &WorkflowData{
    // ...
    RunnerConfig: data.RunnerConfig, // propagate runner.topology (e.g. arc-dind) to the detection job
    // ...
}

Tests

TestBuildDetectionEngineExecutionStepArcDindTopology in threat_detection_test.go:

• arc-dind: detection emits "Copy Copilot CLI to daemon-visible path" and the harness invocation uses ${RUNNER_TEMP}/gh-aw/bin/copilot
• non-arc-dind regression: detection still uses /usr/local/bin/copilot with no staging step

[pelikhan]

@copilot apply fix to evals job as well

[Copilot]

Pull request overview

Fixes threat-detection silently no-op’ing on arc-dind runners by propagating RunnerConfig into the detection job’s WorkflowData, ensuring arc-dind-specific Copilot CLI staging and the daemon-visible spawn path are applied consistently.

Changes:

• Propagate RunnerConfig when constructing threatDetectionData so isArcDindTopology(...) works for the detection job.
• Add a regression test covering arc-dind vs non-arc-dind behavior for detection engine installation/execution steps.

Show a summary per file

File	Description
pkg/workflow/threat_detection_inline_engine.go	Propagates RunnerConfig into the detection job’s WorkflowData so arc-dind handling triggers.
pkg/workflow/threat_detection_test.go	Adds regression coverage asserting arc-dind emits the Copilot staging step and uses the daemon-visible Copilot path.

Review details

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

• Files reviewed: 2/2 changed files
• Comments generated: 1
• Review effort level: Low

[Copilot]

@copilot apply fix to evals job as well

Done in commit fix: propagate RunnerConfig to evals job; strengthen arc-dind test assertions.

Changes made:

1. evals_steps.go: Added RunnerConfig: data.RunnerConfig to evalsData in buildEvalsEngineSteps, mirroring the detection job fix.
2. evals_steps_test.go: New TestBuildEvalsEngineStepsArcDindTopology test covering both arc-dind (staging step + daemon-visible harness path) and non-arc-dind (no staging, /usr/local/bin/copilot) cases.
3. threat_detection_test.go: Strengthened the arc-dind assertion to check copilot_harness.cjs ${RUNNER_TEMP}/gh-aw/bin/copilot specifically in the harness invocation line, avoiding the false positive the reviewer flagged (the staging cp command also contains that substring).

[gh-aw-bot]

@copilot please run the pr-finisher skill, address the latest maintainer feedback about applying this fix to the evals job as well, and rerun checks once the branch is up to date.

Generated by 👨‍🍳 PR Sous Chef · 6.67 AIC · ⌖ 8.02 AIC · ⊞ 7.1K · ◷
_{Comment /souschef to run again}

[github-actions]

🎉 This pull request is included in a new release.

Release: v0.82.7