Add configurable pull-retry timing test seam

What does this MR do?

Adds a configurable test seam for the docker image-pull retry loop (pull.WithPullRetryConfig / docker.SetPullRetryConfigForTesting), and uses it in TestDockerCommandPullRetriesTransientRegistryFailure so the test no longer races production's real 2-10s jittered backoff over only 3 attempts. It now runs with a much larger attempt budget and a much shorter backoff, leaving far more timing margin under CI scheduling jitter while staying fast.

Why was this MR needed?

Follows up on review feedback on !6924 (comment 3553511874), which pointed out that the retry test's flakiness comes from hardcoded retry timing in production code, and suggested a functional-option seam so tests could override it.

What's the best way to test this MR?

  • executors/docker/internal/pull unit tests, including the new TestNewManagerWithPullRetryConfigOption, which proves the option is wired into the retry loop and not just setting unread fields.
  • TestDockerCommandPullRetriesTransientRegistryFailure (build tags integration,network_faults, needs a real docker daemon) still exercises the real retry path end to end, just with a tighter timing budget.

What are the relevant issue numbers?

N/A

Merge request reports

Loading
Loading