zbm-builder.sh: Use -d for custom container CLI

[noelleleigh]

This PR changes the -d argument of zbm-builder.sh to accept an executable argument, which will be used in place of podman or docker. The container-building docs have been updated to mention the ability to use a docker-compatible CLI.

For example, to run the script using nerdctl:

./zbm-builder.sh -d nerdctl

The choice of container CLI follows this priority list:

1. -d argument
2. PODMAN variable in zbm-builder.conf
3. podman
4. docker

Specifying the PODMAN variable with env isn't supported, because the value would be overwritten by the value from zbm-builder.conf when it gets sourced.

[ahesford]

I'm vacillating between wanting to see this change respect $PODMAN in the environment and not really caring. We could guard the current default assignment with if [ -z "${PODMAN}" ] and move it right after the configuration file is sourced (and right before the second option parsing) and get this for free. On the other hand, one could just do

zbm-builder.sh -d "${PODMAN}"

and be done.

If you are inclined to make this change, I'll accept it; if not, I won't bother adding it independently.

[noelleleigh]

[...] We could guard the current default assignment with if [ -z "${PODMAN}" ] and move it right after the configuration file is sourced (and right before the second option parsing) and get this for free.

I tried this while implementing this feature, and it didn't work the way I wanted. To me, this is the ideal order of precedence for controlling this setting:

1. -d nerdctl
2. env PODMAN=nerdctl
3. PODMAN=nerdctl in zbm-builder.conf
4. Search for podman
5. Search for docker

However, to allow env PODMAN to override the contents of zbm-builder.conf, the environment variable would need to be captured before the config is sourced, then re-applied afterwards. I found possible solutions in this StackOverflow question, but at that point it felt overengineered, especially for a single variable, and I wasn't sure what side effects it might have, so I decided to scrap the idea.

Given that, do you still think it's worth adding the extra logic required for supporting env PODMAN precedence?

[ahesford]

I'm sorry, this slipped past me. I agree that it isn't worthwhile to delve further into supporting the environment variable. The changes are fine as they are now; please squash all the commits down (you can leave out the explanatory text in favor of a one-liner commit message).

[noelleleigh]

I'm sorry, this slipped past me. I agree that it isn't worthwhile to delve further into supporting the environment variable. The changes are fine as they are now; please squash all the commits down (you can leave out the explanatory text in favor of a one-liner commit message).

Done 👍 f62b247