build from API or podman-remote build does not supports --userns=auto while it works with CLI

[flouthoc]

User trying this implementation in Podman 4.2.0. Seems its working via CLI, but API call does not work.

Dockerfile

cat << EOF > Dockerfile
FROM alpine
RUN cat /proc/self/uid_map
EOF

Works correctly via CLI

podman build -t test --userns=auto .

Does not work via API

tar -czf context.tar.gz Dockerfile
curl -s --unix-socket /run/podman/podman.sock -X POST  -H "Content-Type:application/tar"  --data-binary "@context.tar.gz"   'http://d/v4.2.0/libpod/build?userns=auto'

Originally posted by @lukasmrtvy in containers/buildah#4060 (comment)

[flouthoc]

@lukasmrtvy PR #15477 should fix this issue, this was not working for remote and API and was missed because tests were automatically skipped in podman CI, reason is buildah tests which are executed in podman CI runs on environment where these tests are automatically skipped due to following condition https://github.com/containers/buildah/blob/main/tests/bud.bats#L259

As a solution new test is added in podman as well which supports right environment so hopefully this will not break in future.

[flouthoc]

Raw API usage is similar to how @giuseppe has mentioned here #15278 (comment) i.e you must populate additional idmappingoption in request payload.

[lukasmrtvy]

@flouthoc Hey, ping

From the IRC disscusion.. Podman 4.3.0 has broken --userns=auto support for multiple ephemeral containers

[root@ip-10-2-20-212 test]# podman -r build -t test --no-cache --userns=auto .
STEP 1/3: FROM alpine
STEP 2/3: RUN echo fo
fo
--> c6bb757f3b9
time="2022-10-31T16:51:02Z" level=error msg="error deleting build container \"7b897b1a077aaecfb44d10cc0df82cd3723b00f95b439a057975a55c4c0e68c7\": identifier is not a container\n"
Error: identifier is not a container: preparing container for next step: creating build container: creating container: the container needs a user namespace with size '�' that is bigger than the maximum va
lue allowed with userns=auto '𐀀'

Seems there is an extended test containers/buildah#4392 for it. but are We tracking fix for this? Thanks

[flouthoc]

@lukasmrtvy Yes this be getting automatically tested cause following test will also run for podman-remote so it will get tested eventually on vendor and if containers/buildah#4392 does not works with podman-remote then vendor will eventually fail blocking new release.

I will try checking this manually in few days as soon as i have some more cycles.