Description
Pack's default pull policy is always, which means that on every pack build, it attempts to pull images even if they exist locally (eg the builder image, run image and any buildpacks specified via docker:// URNs).
This is great for ensuring users don't accidentally build against outdated images, however:
- It adds several seconds to every
pack build (even for a no-op when images are up to date)
- It counts against the container registry's rate limits (even for a no-op), which is inconvenient given Docker Hub and ECR's fairly low rate limits for unauthenticated requests.
These issues are particularly problematic when running integration tests, where pack build will be run many times.
Using the if-not-present pull policy (either via Pack global config, or by passing --pull-policy if-not-present to pack build), prevents these issues, however:
- For CI: It's easy to forget to set the global pack pull policy to
if-not-present, which can mean much slower integration tests (which can be hard to spot, given the Pack stdout mentioning pulling would typically be hidden in the test runner output unless the test fails).
- When using pack locally: It risks using out of date images.
Proposed solution
- Initially: Add support for a new Pack pull policy option (alongside the existing
always and if-not-present options), that only pulls new images if the time since last pull of those images is greater than N hours/days.
- Later on: Make this new pull policy the default, instead of
always. This would (a) mean users get the performance benefit locally without having to know that the pull policy option exists, (b) reduce the boilerplate needed (and chance of forgetting to set it) in CI configs.
Open questions
- Should the new pull policy allow the user to configure the time interval?
- If yes, via what syntax? eg
interval=1d
- If no, what should the hardcoded interval be? 1 day?
- What should the new pull policy be called? Examples:
--pull-policy interval=1d
--pull-policy if-not-recent
--pull-policy if-not-pulled-recently
- How should the state of last pull time for each image be tracked?
Describe alternatives you've considered
- Modify integration test runners to pass
--pull-policy if-not-present to pack build both locally and in CI:
- Pros: This will speed up integration tests everywhere.
- Cons: Users can potentially be integration testing against out of date images locally (if they don't also run
pack build manually from time to time, which would pull). Doesn't help speed up manual repeat pack builds locally when developing.
- Modify integration test runners to pass
--pull-policy if-not-present to pack build only in CI:
- Pros: This will speed up integration tests in CI. No risk of running integration tests locally against stale images.
- Cons: Doesn't help speed up integration tests locally, or running manual repeat
pack builds locally when developing. Means having to add vendor-specific CI checks (eg known env vars) in integration test runners.
- In the CI config only, set the Pack global pull policy to
if-not-present:
- Pros: This will speed up integration tests in CI. No risk of running integration tests locally against stale images. No vendor-specific checks in integration test runners.
- Cons: Doesn't help speed up integration tests locally, or running manual repeat
pack builds locally when developing. Easy to forget to configure (particularly when the end user projects are owned by different users to the test runner, so less familiar with best practices).
Additional context
Description
Pack's default pull policy is
always, which means that on everypack build, it attempts to pull images even if they exist locally (eg the builder image, run image and any buildpacks specified viadocker://URNs).This is great for ensuring users don't accidentally build against outdated images, however:
pack build(even for a no-op when images are up to date)These issues are particularly problematic when running integration tests, where
pack buildwill be run many times.Using the
if-not-presentpull policy (either via Pack global config, or by passing--pull-policy if-not-presenttopack build), prevents these issues, however:if-not-present, which can mean much slower integration tests (which can be hard to spot, given the Pack stdout mentioning pulling would typically be hidden in the test runner output unless the test fails).Proposed solution
alwaysandif-not-presentoptions), that only pulls new images if the time since last pull of those images is greater than N hours/days.always. This would (a) mean users get the performance benefit locally without having to know that the pull policy option exists, (b) reduce the boilerplate needed (and chance of forgetting to set it) in CI configs.Open questions
interval=1d--pull-policy interval=1d--pull-policy if-not-recent--pull-policy if-not-pulled-recentlyDescribe alternatives you've considered
--pull-policy if-not-presenttopack buildboth locally and in CI:pack buildmanually from time to time, which would pull). Doesn't help speed up manual repeatpack builds locally when developing.--pull-policy if-not-presenttopack buildonly in CI:pack builds locally when developing. Means having to add vendor-specific CI checks (eg known env vars) in integration test runners.if-not-present:pack builds locally when developing. Easy to forget to configure (particularly when the end user projects are owned by different users to the test runner, so less familiar with best practices).Additional context