Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Image pull policy #1345

Merged
merged 43 commits into from
Nov 1, 2019
Merged

Conversation

dmarkhas
Copy link
Contributor

This is an attempt to address #1324 and provide a means of specifying the way the library should handle pulling images with static tags.
I expect there will be some comments 😄

@FunctionalInterface
public interface ImagePullPolicy {

boolean shouldPull(Image image);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel uneasy about using docker-java's classes in our public APIs where otherwise possible.
Could you please add a simple interface for the Image? ☺️

Also, I'm not sure we should use Image here.
As a pull policy developer, I do not expect an instance of image available before I decide how to pull it. Maybe the name isn't correct and it should be something like ImageRefreshPolicy?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I can avoid exposing Image.
As for the name - I "borrowed" the Kubernetes term but I have no strong feelings either way. I think it makes sense to assume the policy dictates the behavior when an image exists locally, otherwise the library will always pull it from a remote registry, but I'm OK with changing it.

One thing I changed and would like your feedback on is the fact that the ctor of GenericContainer was triggering the docker pull flow immediately (by resolving the Future) - this seemed strange to me, because it means this flow would run even if the container is never used at all. Also this would've prevented me from adding the imagePullPolicy because by that time the image would have already been pulled (or not).
So I moved this step to configure() instead - is that OK?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rnorth WDYT?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm totally OK with moving the image pull behaviour out of the constructor. This is really quite a longstanding itch; the intention was to enable 'fail-fast' if a bad image was specified, but it's generally caused a fair amount of confusion.

👍 for changing this.

import org.testcontainers.containers.image.ImageData;

@Slf4j
public class DefaultPullPolicy implements ImagePullPolicy {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can imagine that this will be the place people go to look for javadocs on the default policy, so please could there be class javadocs describing it here? Maybe lift what's on PullPolicy to the classes, and reduce the method-level javadocs there to links.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have unresolved this because I don't think it is actually resolved.

@dmarkhas please keep the conversations open, the reporters will resolve them when they feel so :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bsideup this class now contains javadocs that describe its function, why do you think it is not resolved?

@dmarkhas
Copy link
Contributor Author

The test failure seems unrelated to any of my changes, is it possible to re-trigger the CI pipeline?

@dmarkhas
Copy link
Contributor Author

Thanks @bsideup 🐱
On 2nd thought I prefer the current terminology of imagePullPolicy over imageRefreshPolicy, since there is no concept of "image refresh" in the Docker nomencalture, whereas it is clear what "pull policy" implies and what behavior it would affect.

@dmarkhas
Copy link
Contributor Author

dmarkhas commented Apr 3, 2019

So, um, is anyone going to merge this? 😄

import com.google.common.base.Strings;
import lombok.*;
import java.io.ByteArrayInputStream;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please avoid changing the imports order and star-imports

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is not resolved yet. Also, please do not resolve other's conversations to keep them visible until they are actually resolved.

@tyagiakhilesh
Copy link

Looks like all the checks have passed. Can we take it forward ?

@mangan77
Copy link

Any plans to get this merged?

@tschmidt01
Copy link

Waiting for the merge too.

@rnorth rnorth self-assigned this Oct 3, 2019
@rnorth rnorth added this to the next milestone Oct 3, 2019
@bsideup bsideup modified the milestones: 1.12.3, next Oct 26, 2019
@bsideup bsideup assigned bsideup and unassigned rnorth Nov 1, 2019
@bsideup bsideup changed the base branch from master to image_pull_policy November 1, 2019 21:29
@bsideup bsideup merged commit 6b19f04 into testcontainers:image_pull_policy Nov 1, 2019
@bsideup
Copy link
Member

bsideup commented Nov 1, 2019

@dmarkhas I just merged your PR into a branch in the main repo and will make some adjustments, so that we can merge it to master soon 👍
Thank you!

bsideup added a commit that referenced this pull request Nov 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants