Issue Description
I've noticed that buildah build and podman build --squash both produce a RootFS layer of sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef even if there are no RootFS-impacting instructions in the Containerfile. Observing an image with this layer, it contains no content but still ends in the RootFS.layers blob.
Steps to reproduce the issue
Steps to reproduce the issue
- Build this image using
buildah build <file>
from registry.fedoraproject.org/fedora@sha256:dd93b388ec7b1da2055d2234532499526cef6a799de80f95a923f293602dd462 as base
LABEL foo=bar
❯ podman image inspect <imageid> | jq '.[0].RootFS.Layers'
[
"sha256:35fccc735c0f5e9fe7c672e3162d8ee5b515e21d0de850026752bb4c1806a51a",
"sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef"
]
- Optionally inspect the content associated with
sha256:5f70b... and notice it's empty.
Describe the results you received
"sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef" shows up as the final layer in RootFS.Layers for the image.
Describe the results you expected
As it does not contain filesystem-impacting content, I would not expect this to be in the RootFS.Layers list.
buildah version output
VERSION: buildah version 1.43.1 (image-spec 1.1.1, runtime-spec 1.2.1)
RPM: buildah-1.43.1-1.fc43.x86_64
buildah info output
{
"host": {
"CgroupVersion": "v2",
"Distribution": {
"distribution": "fedora",
"version": "43"
},
"MemFree": 1716559872,
"MemTotal": 67100418048,
"OCIRuntime": "crun",
"SwapFree": 8310710272,
"SwapTotal": 8589930496,
"arch": "amd64",
"cpus": 16,
"hostname": "my-hostname",
"kernel": "7.0.8-100.fc43.x86_64",
"os": "linux",
"rootless": true,
"uptime": "73h 52m 44.22s (Approximately 3.04 days)",
"variant": ""
},
"store": {
"ContainerStore": {
"number": 107
},
"GraphDriverName": "overlay",
"GraphImageStore": "",
"GraphOptions": null,
"GraphRoot": "/home/username/.local/share/containers/storage",
"GraphStatus": {
"Backing Filesystem": "btrfs",
"Native Overlay Diff": "true",
"Supports d_type": "true",
"Supports shifting": "false",
"Supports volatile": "true",
"Using metacopy": "false"
},
"GraphTransientStore": false,
"ImageStore": {
"number": 891
},
"RunRoot": "/run/user/107112/containers"
}
}
Provide your storage.conf
Upstream Latest Release
Yes
Additional environment details
Additional environment details
Additional information
No response
Issue Description
I've noticed that
buildah buildandpodman build --squashboth produce a RootFS layer ofsha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6efeven if there are no RootFS-impacting instructions in the Containerfile. Observing an image with this layer, it contains no content but still ends in the RootFS.layers blob.Steps to reproduce the issue
Steps to reproduce the issue
buildah build <file>sha256:5f70b...and notice it's empty.Describe the results you received
"sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef"shows up as the final layer in RootFS.Layers for the image.Describe the results you expected
As it does not contain filesystem-impacting content, I would not expect this to be in the RootFS.Layers list.
buildah version output
buildah info output
Provide your storage.conf
n/aUpstream Latest Release
Yes
Additional environment details
Additional environment details
Additional information
No response