Containerfile.in not automatically pre-processed

[cevich]

Issue Description

The podman build (and buildah build) documentation currently says:

Containerfiles ending with a ".in" suffix are preprocessed via CPP(1). This can be useful to decompose Containerfiles into several reusable parts that can be used via CPP's #include directive. Containerfiles ending in .in are re‐ stricted to no comment lines unless they are CPP commands. Note, a Containerfile.in file can still be used by other tools when manually preprocessing them via cpp -E.

At least to me, this makes it sound like a podman build . should automatically pick up a Containerfile.in and pre-process it for #include "foo.bar" type directives.

Steps to reproduce the issue

Steps to reproduce the issue

1. echo '#include "./foo.bar"' > Containerfile.in
2. echo 'FROM scratch' > foo.bar
3. podman build .

Describe the results you received

Error: no Containerfile or Dockerfile specified or found in context directory

Describe the results you expected

STEP 1/1: FROM scratch
COMMIT test
--> 885c95a5d7b8
Successfully tagged localhost/test:latest
885c95a5d7b8d384ded58fc72ae4fefcf7f08c0de160b9b6915c2814fe692897

(Simulated using podman build -t test -f Containerfile.in .)

podman info output

If you are unable to run podman info for any reason, please provide the podman version, operating system and its version and the architecture you are running.

Podman in a container

No

Privileged Or Rootless

None

Upstream Latest Release

No

Additional environment details

Tested with podman v5.1.0 in F40

Additional information

A documentation "fix" could be done here, but I'm sure many/most users would expect podman (and buildah) to simply pick up the Containerfile.in is present and a Containerfile is absent.

[Luap99]

I am not sure if adding yet two more location that are checked by default are so useful.

I would argue we should just make the docs more clear.

For this document, a file referred to as a Containerfile can be a file named either 'Containerfile' or 'Dockerfile'.

So there is that already. However the docs never really say how the default context directory is "searched"

[cevich]

However the docs never really say how the default context directory is "searched"

For a "Docs fix", I think it should specify that and that the -f argument is required to take advantage of Containerfile.in. I'm not a big fan, but I think this would be an acceptable short-term solution. Perhaps fixing the search could then be an RFE.

OTOH, in terms of POLA, I think there's little merit to an argument for a "just works" search here. Something like: Containerfile.in -> Containerfile -> Dockerfile.

I think users DO expect features like this to not require extra arguments, documented or not. Nobody "wants" to have to go RTFM when something doesn't work the simple way. They want the developers to have anticipated their needs/desires (to a reasonable extent) accordingly.