[code-simplifier] refactor: use isCliProxyNeeded() in docker.go to remove logic duplication

[github-actions]

This PR simplifies recently modified code from PR #26154 to improve clarity and maintainability while preserving all functionality.

Files Simplified

• pkg/workflow/docker.go — replaced duplicated inline cli-proxy check with the existing isCliProxyNeeded() function

Improvement

PR #26154 added isCliProxyNeeded() in compiler_difc_proxy.go to encapsulate the logic for when the CLI proxy should be started (checking both the explicit cli-proxy feature flag and the implicit integrity-reactions trigger, plus firewall and version checks).

However, docker.go still had its own inline version of the first part of that logic:

// Before
cliProxyNeeded := isFeatureEnabled(constants.CliProxyFeatureFlag, workflowData) ||
    isFeatureEnabled(constants.IntegrityReactionsFeatureFlag, workflowData)
if cliProxyNeeded && awfSupportsCliProxy(firewallConfig) {

Replaced with a single call to the authoritative function:

// After
if isCliProxyNeeded(workflowData) {

This eliminates the duplication and ensures that if the proxy enablement conditions ever change, both the step generation and the image collection paths update together.

Changes Based On

• fix: correct integrity level descriptions and auto-enable cli-proxy for reactions #26154 — fix: correct integrity level descriptions and auto-enable cli-proxy for reactions

Testing

• ✅ All related tests pass (TestCollectDockerImages_CliProxy, TestIsCliProxyNeeded_IntegrityReactionsImplicitEnable)
• ✅ Build succeeds (make build)
• ✅ No functional changes — behavior is identical

Review Focus

Please verify:

• Functionality is preserved (docker image collection for cli-proxy is unchanged)
• The simplification correctly delegates to isCliProxyNeeded() without behavioral differences

---

Automated by Code Simplifier Agent — analyzing code from the last 24 hours

Generated by Code Simplifier · ● 1.1M · ◷

• expires on Apr 15, 2026, 6:20 AM UTC

[github-actions]

Hey @github-actions[bot] 👋 — nice cleanup! Using the existing isCliProxyNeeded() function to replace the inline duplicate logic in docker.go is exactly the kind of maintenance refactor that keeps the codebase healthy and avoids future divergence.

One minor note:

• No test diff included — the PR doesn't touch any test files. Since isCliProxyNeeded() now also incorporates the awfSupportsCliProxy(firewallConfig) check (which the old inline code included), it's worth confirming TestCollectDockerImages_CliProxy covers the case where the firewall config would not support the proxy — to make sure that guard is still exercised via the new call path.

If you'd like a hand addressing this, you can assign this prompt to your coding agent:

In pkg/workflow/docker_test.go, review the existing TestCollectDockerImages_CliProxy test.
Check whether there is a test case that verifies the cli-proxy image is NOT added when
awfSupportsCliProxy returns false (e.g., when the AWF version is too old or firewall config
is missing). If such a case is absent, add one to ensure the isCliProxyNeeded() delegation
in docker.go still respects the awfSupportsCliProxy guard.

Generated by Contribution Check · ● 1.4M · ◷

[Copilot]

Pull request overview

Refactors collectDockerImages to delegate CLI proxy enablement logic to the existing isCliProxyNeeded() helper, reducing duplicated conditional logic and keeping CLI-proxy image pulling aligned with step generation behavior.

Changes:

• Replaced inline cli-proxy / integrity-reactions feature-flag checks in docker image collection with a single isCliProxyNeeded(workflowData) call.
• Simplified the related comment block in docker.go.

Show a summary per file

File	Description
pkg/workflow/docker.go	Uses isCliProxyNeeded() to decide whether to include the cli-proxy AWF sidecar image in the pre-pull list.

Copilot's findings

Tip

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

• Files reviewed: 1/1 changed files
• Comments generated: 2

[Copilot]

collectDockerImages now relies on isCliProxyNeeded(), but docker_cli_proxy_test.go doesn’t currently cover the implicit enablement path via features.integrity-reactions: true. Adding a test case that asserts the cli-proxy image is included when integrity-reactions is enabled (and excluded when AWF is too old / firewall disabled) would protect this refactor from regressions and verify the image-collection path stays aligned with step generation.

[Copilot]

isCliProxyNeeded(workflowData) re-checks isFirewallEnabled() and re-derives firewallConfig internally, even though this block already established firewall is enabled and already computed firewallConfig/awfImageTag. This adds redundant work and can emit difc_proxy debug logs from the image-collection path; consider adding a helper that accepts the already-computed firewallConfig (or splitting feature-flag evaluation from firewall/version gating) so docker image collection doesn’t repeat checks.