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

ENH: buildah bud should cache layers by default? #1455

Closed
h-vetinari opened this issue Mar 28, 2019 · 4 comments
Closed

ENH: buildah bud should cache layers by default? #1455

h-vetinari opened this issue Mar 28, 2019 · 4 comments

Comments

@h-vetinari
Copy link

[Now that I have access to the nightly ppa's (cf. containers/podman#2250), I'm starting to file some issues against podman - and since the issue template there says that podman build issues should be filed for buildah, I'm starting here.]

In the spirit of the podman credo

What is Podman? Simply put: alias docker=podman

podman build actually uses caching, so I was surprised that buildah bud does not. Is there a reason it should not be enabled by default? Should podman build [dockerfile] == buildah bud [dockerfile], or are the differences documented somewhere?

Also the --layers parameter is not obvious to find, for example, it's mentioned nowhere in the tutorials.

@TomSweeneyRedHat TomSweeneyRedHat self-assigned this Mar 28, 2019
@TomSweeneyRedHat
Copy link
Member

I'll let @rhatdan or @nalind correct me, but the reasoning for --layers=false (no-cache) for buildah bud was the thought that Buildah would be used for proof-of-concept types of container builds and you wouldn't need the caching in that case. Meanwhile Podman with podman bulid was meant for more of a production type environment, so most people would want the default --layers=true (cache) for that environment.

You bring up a good point on the difference use of --layers between the two projects not being really visible other than in the man pages. Even there the reasoning for the difference isn't highlighted well or possibly at all. I'll see if we can add some verbiage in a place or two to more fully explain this.

@h-vetinari
Copy link
Author

Thanks for the response!

@TomSweeneyRedHat: [...] the reasoning for --layers=false (no-cache) for buildah bud was the thought that Buildah would be used for proof-of-concept types of container builds and you wouldn't need the caching in that case.

Well, even if I'm developing a container, and changing something in (say) step 15, I don't want to have to wait needlessly for steps 1-14 to rerun. To the contrary, turning off the cache with --no-cache is only necessary for me when needing to force a recalculation for some reason.

@rhatdan
Copy link
Member

rhatdan commented Mar 29, 2019

@h-vetinari Sorry for the confusion.

The thought was that buildah would be used more often in CI/CD systems while podman build is more often used to develop container images using Dockerfile.

If you are building a container image in a CI/CD system having every RUN/COPY/ADD command create a layer makes no sense.

Note you can easily change the default for either PODMAN or BUILDAH using environment variables.

man buildah
...
       --layers bool-value

       Cache intermediate images during the build process (Default is false).

       Note: You can also override the default value of layers by setting the BUILDAH_LAYERS  environment  variable.  export  BUILDAH_LAYERS=true
buildah bud --help | grep -- --layers
      --layers                        cache intermediate layers during build. Use BUILDAH_LAYERS environment variable to override. (default false)
man podman build
...
       --layers

       Cache intermediate images during the build process (Default is true).

       Note: You can also override the default value of layers by setting the BUILDAH_LAYERS environment variable. export  BUILDAH_LAYERS=true
 podman build --help | grep -- --layers
  podman build --layers --force-rm --tag imageName .
      --layers                                     cache intermediate layers during build. Use BUILDAH_LAYERS environment variable to override. (default true)

Do you think the man pages is not descriptive enough?

@rhatdan
Copy link
Member

rhatdan commented Jun 8, 2019

I believe this is documented well enough.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants