Don't fail when a builder or stack image cannot be pulled

[ekcasey]

No Remote Builder Image

Given I have run pack build --builder <builder-image> without the --no-pull flag
Given there is a local version of the builder image
When pack attempts to pull the image and the registry returns any error
Then pack should continue executing without error

No Remote Builder Image and No Local Builder Image

Given I have run pack build --builder <builder-image> without the --no-pull flag
Given there is not a local version of the builder image
When pack attempts to pull the image and the registry returns any error
Then pack should error out

*The fix for this will involve changes to the image package in buildpacks/lifecycle

PM Acceptance Criteria
Case #1
When I build an image with pack build my-image
And A remote copy of:

• The builder or
• The associated run image
  is not available
  And A local copy of the image is available
  Then The local copy is silently used for the build

Case #2
When I build an image with pack build my-image
And A remote copy of:

• The builder or
• The associated run image
  is available
  And A local copy of the image is available
  Then The remote copy of the image is pulled and used for the build

Notes

• Let PM know if there's a class of errors for retrieving the remote image that you think we should fail on

[josegonzalez]

In the first scenario, did you mean with?

[ekcasey]

@josegonzalez

When --no-pull is passed we don't attempt to pull at all. This behavior should not change.

Without the flag, I believe we should attempt to pull but permit a missing remote image. Rather than assuming that this is a failure case, I want to interpret it as a success, as in "we successfully ensured the image was as up to date as possible".

We should probably print some info about whether a new version was fetched.

thoughts?

[josegonzalez]

I guess I'm parsing this with the same Given, hence my confusion.

I would say that if there is no tag specified on the image, latest should be used. That seems reasonable enough.

Does the absence of the --no-pull flag imply --pull? If so, then it would seem that a failing pull should fail the build. Not failing would be closer to in semantics to --try-pull, right?

[ekcasey]

I tried to make the intent more clear in the description, let me know if I succeeded

The intention of pulling by default is to ensure that users have the most up-to-date base images and buildpacks. However, if there is no remote image it implies that the user is using a locally created builder or stack and there is no way to update. Several users who are developing buildpacks have said that this behavior is annoying. Most users who are attempting to create a builder immediately run into this error.

The case we are guarding against now doesn't seem to describe many real world scenarios. I have trouble imagining a case where the user wants to update the builder or run image and needs to be informed that it doesn't exist

[nebhale]

I think a warning that pull was unsuccessful but allowing progress is appropriate.

[jchesterpivotal]

For reference, registry v2 error codes.

[mgibson1121]

This story passes acceptance.