Allow if-not-present pull policy for builds with image extensions

[MoritzWeber0]

Description

When running pack build and the builder contains image extensions, the build fails with:

ERROR: failed to build: pull policy must be 'always' when builder contains image extensions

Proposed solution

The pack build command should accept --pull-policy if-not-present as argument, also if the builder contains image extensions.

Additional context

I don't want to rely on a local registry or internet connection when building my images locally.

[jjbustamante]

Make sense to me, but no sure if @natalieparellano has some thoughts about it

[natalieparellano]

The issue with --pull-policy if-not-present is that we will not get a manifest for an image that only exists in the daemon (though with newer versions of docker using containerd as the backing store, that will hopefully one day be possible).

However, I believe some recent changes to imgutil (see https://github.com/buildpacks/imgutil/blob/main/local/v1_facade.go) should make it possible to construct a dummy manifest that may be good enough for our purposes (kaniko). We should do an exploration for it.

[hhiroshell]

Could you please assign this to me? This issue involves a slightly deeper implementation of the pack than those I've worked on before, but I’d like to take on more challenging tasks.

Anyway, I'm thinking about start with this exploration. I’d appreciate any advice you could share.

[natalieparellano]

@hhiroshell thank you for looking into this, and apologies for the slow reply - after digging into this a little further, I think this issue might make more sense on the lifecycle as the bulk of the effort would be there, although both pack and the lifecycle would require changes.

• Here is where we enforce in pack that the pull policy must be 'always' in order to use extensions
• Here is where the lifecycle assumes that the provided base image for extensions must exist in a registry; if you replace the call to remote.NewImage with local.NewImage, the returned image (because of the mentioned changes in imgutil) should still work.

That should be sufficient as an exploration. To make this a "real" feature, we'd want to inspect the -daemon flag in the restorer in order to instantiate a remote or local image depending on the type of build. And, we'd want to liberally test this, by adding to the acceptance tests for extensions in both pack and the lifecycle to ensure that builds work as expected with this change. Finally we'd probably want to clarify and update the spec as I believe the "remote only" restriction is mentioned in a couple of places.

Unfortunately, this may be a little difficult to work on without guidance from someone with a lot of context. I have worked a lot on extensions, but I am about to step away for several months. I don't want to discourage anyone from looking into this however, as it would be good for others to build context, just cautioning that a fair amount of discovery may be needed!

Hope this is helpful. Best of luck!

[hhiroshell]

Hi @natalieparellano,
I’m sorry for not making progress on this yet. I’ve been quite busy with various events, including attending KubeCon.

Thank you so much for your helpful guidance—it’s been invaluable. It seems like there’s a lot of work to do, but now that the tasks are somewhat clear, I believe we can make progress.

And I’m truly sorry to hear that you’re stepping away... 😢