Loading
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/pullunit tests, including the newTestNewManagerWithPullRetryConfigOption, which proves the option is wired into the retry loop and not just setting unread fields.TestDockerCommandPullRetriesTransientRegistryFailure(build tagsintegration,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