Add a flag to build the image from a file

[KilianHanich]

Hello,

this PR is about #1397. It adds two flags:

• --build to specify a build-context which is then passed to podman build
• --build-tag to optionally specify how the built image should be named; it passes the argument to podman build --tag

I changed the files under doc to reflect the changed and added a few bats test cases.

I can add more if these are wanted, but I currently don't think more are needed for this feature.

[softwarefactory-project-zuul[bot]]

Build failed. https://softwarefactory-project.io/zuul/t/local/buildset/04aaaad3091b45748c692c3d8d7475e8

:heavy_check_mark: unit-test SUCCESS in 5m 00s :x: unit-test-migration-path-for-coreos-toolbox FAILURE in 2m 57s :heavy_check_mark: unit-test-restricted SUCCESS in 3m 54s :x: system-test-fedora-rawhide FAILURE in 35m 37s :x: system-test-fedora-39 FAILURE in 33m 51s :x: system-test-fedora-38 FAILURE in 36m 00s

[KilianHanich]

Would be nice to know how this error wasn't caught by building it locally, but whatever.

[softwarefactory-project-zuul[bot]]

Build failed. https://softwarefactory-project.io/zuul/t/local/buildset/e93ff974735f48d6ac1e3893675b7e87

:heavy_check_mark: unit-test SUCCESS in 4m 52s :heavy_check_mark: unit-test-migration-path-for-coreos-toolbox SUCCESS in 3m 35s :heavy_check_mark: unit-test-restricted SUCCESS in 3m 54s :x: system-test-fedora-rawhide FAILURE in 35m 48s :x: system-test-fedora-39 FAILURE in 34m 02s :x: system-test-fedora-38 FAILURE in 34m 25s

[KilianHanich]

Ok, I have no idea what the problem with this error is.

It's calling "podman images" that fails, but it works on my machine for some reason.

[softwarefactory-project-zuul[bot]]

Build failed. https://softwarefactory-project.io/zuul/t/local/buildset/629f647fc7fb4d8ea59bfeb7ebb221ff

:heavy_check_mark: unit-test SUCCESS in 4m 48s :heavy_check_mark: unit-test-migration-path-for-coreos-toolbox SUCCESS in 3m 32s :heavy_check_mark: unit-test-restricted SUCCESS in 3m 55s :x: system-test-fedora-rawhide FAILURE in 41m 10s :x: system-test-fedora-39 FAILURE in 33m 48s :x: system-test-fedora-38 FAILURE in 34m 50s

[softwarefactory-project-zuul[bot]]

Build failed. https://softwarefactory-project.io/zuul/t/local/buildset/1030f61da6e34eeca05dccca9e8075de

:heavy_check_mark: unit-test SUCCESS in 4m 55s :heavy_check_mark: unit-test-migration-path-for-coreos-toolbox SUCCESS in 3m 44s :heavy_check_mark: unit-test-restricted SUCCESS in 3m 54s :x: system-test-fedora-rawhide TIMED_OUT in 1h 20m 25s :x: system-test-fedora-39 FAILURE in 34m 59s :x: system-test-fedora-38 FAILURE in 34m 57s

[softwarefactory-project-zuul[bot]]

Build failed. https://softwarefactory-project.io/zuul/t/local/buildset/ca7ad37c057d493b944c20ebd2c0b50c

:heavy_check_mark: unit-test SUCCESS in 5m 14s :heavy_check_mark: unit-test-migration-path-for-coreos-toolbox SUCCESS in 3m 31s :heavy_check_mark: unit-test-restricted SUCCESS in 4m 05s :x: system-test-fedora-rawhide TIMED_OUT in 1h 20m 25s :x: system-test-fedora-39 FAILURE in 34m 00s :x: system-test-fedora-38 FAILURE in 33m 59s

[softwarefactory-project-zuul[bot]]

Build failed. https://softwarefactory-project.io/zuul/t/local/buildset/2a56c374c8654e8d995dec00cf5c8134

:heavy_check_mark: unit-test SUCCESS in 5m 05s :heavy_check_mark: unit-test-migration-path-for-coreos-toolbox SUCCESS in 3m 10s :heavy_check_mark: unit-test-restricted SUCCESS in 4m 04s :x: system-test-fedora-rawhide TIMED_OUT in 1h 20m 20s :x: system-test-fedora-39 FAILURE in 35m 12s :x: system-test-fedora-38 FAILURE in 34m 47s

[KilianHanich]

One quick question: other than the discussion on the original issue, did you see the discussion on the previously attempted pull request?

Yes, I did.

On the one hand, yes, filesystems are racy and one could ofc guard against stuff.

On the other hand, one just passed a path to the directory with the Containerfile in and guarding against it can be quite annoying.

So, we get a few questions:

• How likely is it to actually be a problem?
• Does this project want the complexity from it? It would require quite a bit more changes to properly do it.
• This option assumes that the Containerfile is at the root of the build context. If the other files in there actually matter but the Containerfile itself changed (or is removed), we don't have any guarantee that these files didn't change either. So, what would such a guard actually guard against? If it's malicious, one can do it just as well via these files. And if it isn't, one has no guarantee that the other files wouldn't be broken (for the build) too.
• Shouldn't this problem be delegated to better builders? (e.g. podman-build, buildah etc.)

Personally I don't think dealing with that is worth it. But ofc if you want that, I would implement it.

[KilianHanich]

On a different note, could it be that podman can't pull something in the tests? Because that would explain the failures...

[KilianHanich]

I think I finally figured out what fails. podman build fails thanks to SELinux...

To be exact, podman outputs at step 6 (RUN rm /etc/rpm/macros.image-language-conf): /bin/sh: error while loading shared libraries: /lib64/libc.so.6: cannot apply additional memory protection after relocation: Permission denied The AVC has as scontext system_u:system_r:container_t:s0:c123,c347 and as tcontext unconfined_u:object_r:cache_home_t:s0.

@debarshiray Do you have an idea about how to fix this? I am not really well versed when it comes to SELinux.