Re: [PATCH 7/8] tools/build-docs-container: allow passing extra args to $OCI run

Quentin Schulz
2026-01-12T13:20:43Z

Hi Antonin,

On 12/22/25 1:27 PM, Antonin Godard wrote:
> Add a OCI_RUN_EXTRA_ARGS env variable to allow customizing the arguments
> passed to the podman/docker run command. For example:
>
> export OCI_RUN_EXTRA_ARGS="--env=SPHINXOPTS=-W --keep-going -j1"
>
> To limit the number of threads used by Sphinx. This is especially useful
> for parallel builds.
>

How about exporting host variables inside the container? That would
allow to not have to add OCI_RUN_EXTRA_ARGS when comparing native with
container's output.

Something like

args_run+=(--env SPHINXOPTS)
args_run+=(--env SPHINXBUILD)
args_run+=(--env VALEOPTS)
args_run+=(--env VALEDOCS)
args_run+=(--env SPHINXLINTDOCS)

(not tested).

Also, you can already do that by simply doing

documentation/tools/build-docs-container leap:15.6 SPHINXOPTS=--bla html

for example.

FYI, I've realized that our "which CONTAINERCMD" doesn't actually work
when you have podman-docker installed. I had an alias in my zshrc
setting docker to podman directly... I need to figure out if there's a
way to detect whether podman-docker is installed and in that case use
podman instead of docker. The user mapping doesn't seem to work though
(using the docker configuration in our script, with podman-docker
installed, so effectively using rootless podman but with docker
arguments). Seems like the owner of files within the container is not
mapped to a host container (all owned by root in the container, which
seems to be the default when a user id doesn't map to anything known on
the host).

/usr/bin/docker is a shell script exec'ing podman with the same args but
the naive check on whether it's a shell script is probably a bad idea,
as nothing guarantees it is a shell script on all distros or that docker
won't suddenly become a shell script itself.

Cheers,
Quentin