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

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

Open
MoritzWeber0 opened this issue Jul 4, 2024 · 3 comments
Open
Assignees
Labels
help wanted Need some extra hands to get this done. status/ready Issue ready to be worked on. type/enhancement Issue that requests a new feature or improvement.

Comments

@MoritzWeber0
Copy link

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.

@MoritzWeber0 MoritzWeber0 added status/triage Issue or PR that requires contributor attention. type/enhancement Issue that requests a new feature or improvement. labels Jul 4, 2024
@MoritzWeber0 MoritzWeber0 changed the title Allow if-not-present pull policy for build with image extensions Allow if-not-present pull policy for builds with image extensions Jul 4, 2024
@jjbustamante
Copy link
Member

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

@natalieparellano
Copy link
Member

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.

@natalieparellano natalieparellano added status/ready Issue ready to be worked on. help wanted Need some extra hands to get this done. and removed status/triage Issue or PR that requires contributor attention. labels Jul 8, 2024
@hhiroshell
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Need some extra hands to get this done. status/ready Issue ready to be worked on. type/enhancement Issue that requests a new feature or improvement.
Projects
None yet
Development

No branches or pull requests

4 participants