Add a flag to build the image from a file
Hello,
this PR is about #1397. It adds two flags:
--buildto specify a build-context which is then passed topodman build--build-tagto optionally specify how the built image should be named; it passes the argument topodman 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.
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
Would be nice to know how this error wasn't caught by building it locally, but whatever.
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
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.
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
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
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
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
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.
On a different note, could it be that podman can't pull something in the tests? Because that would explain the failures...
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.
Build failed. https://softwarefactory-project.io/zuul/t/local/buildset/3da50194cc5d435ca01d8f1e0abf683e
:heavy_check_mark: unit-test SUCCESS in 7m 00s :heavy_check_mark: unit-test-migration-path-for-coreos-toolbox SUCCESS in 3m 28s :heavy_check_mark: unit-test-restricted SUCCESS in 5m 37s :x: system-test-fedora-rawhide FAILURE in 43m 38s :x: system-test-fedora-40 FAILURE in 35m 58s :x: system-test-fedora-39 FAILURE in 35m 49s :x: system-test-fedora-38 FAILURE in 34m 19s
Don't approve of it yet, please.
Build failed. https://softwarefactory-project.io/zuul/t/local/buildset/64d89cec14d04070aabae258897fb5ef
:heavy_check_mark: unit-test SUCCESS in 6m 56s :heavy_check_mark: unit-test-migration-path-for-coreos-toolbox SUCCESS in 3m 29s :heavy_check_mark: unit-test-restricted SUCCESS in 5m 50s :heavy_check_mark: system-test-fedora-rawhide SUCCESS in 43m 18s :x: system-test-fedora-40 FAILURE in 35m 42s :x: system-test-fedora-39 FAILURE in 35m 19s :x: system-test-fedora-38 FAILURE in 34m 28s
Ok, so, there is still one problem here with the build pipeline:
Since bats create a temporary image repository under a tmpdir which are labeled with e.g. unconfined_u:object_r:cache_home_t:s0 which SELinux doesn't like since podman is labeled as system_u:system_r:container_t:s0: with some Multi-Category-Security label.
I tried to locally fix this by running XDG_CACHE_HOME=$HOME/podmanreg bats test/system to make the test suit place the stuff it works on somewhere else and gets a different label. That didn't work since it still can't access files with type user_home_t.
This implementation so far works with the default placement of the images and with SELinux in permissive mode. But I am unsure where to go from here.
I also tested this by creating a VM and set XDG_CACHE_HOME to $HOME/.local/share and creating a symlink from ~/.local/share/toolbx/system-test-storage to ~/.local/share/containers (I didn't want to loose my actual toolboxes after all and cleaned up the contents of ~/.local/share/containers). That worked.
So, the remaining issue is one with the pipeline and I don't know how to proceed with that. @debarshiray, do you have an idea?