Skip to content

Conversation

@cgundy
Copy link
Contributor

@cgundy cgundy commented Jan 20, 2026

This refactors build-image.sh and run-container.sh to simplify them a little. Here are the changes that were made:

build-image.sh:

  • update usage documentation
  • support running with different container commands

container-run.sh:

  • add rebuild option
  • remove support for docker. Previously docker was only supported by half the script, which is confusing. This removes it and explicitly mentions that the script can only be run with podman.
  • remove auto-detection of shell environment. This added a lot of complexity and generally I think it's simpler if it defaults to /usr/bin/bash and creates a more reproducible environment. It's still possible for the user to pass in their own command with a shell specified.

@cgundy cgundy marked this pull request as ready for review January 20, 2026 13:34
@cgundy cgundy requested a review from a team as a code owner January 20, 2026 13:34
@github-actions github-actions bot added the @idx label Jan 20, 2026
Copy link
Contributor

@nmattia nmattia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot! Really nice to see someone give these scripts some love :)

echo " otherwise will choose based on detected environment)"
echo ""
echo "Advanced:"
echo " Set the DOCKER_BUILD_ARGS environment variable to pass additional"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would it make sense to have DOCKER_CMD or simply DOCKER as an env var (instance of --container-cmd) to stay consistent?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe I'll make docker build args into an input as well - I agree it's confusing have the two formats.

Comment on lines 68 to 81
if ! sudo podman "${PODMAN_ARGS[@]}" image exists $IMAGE; then
if ! sudo podman "${PODMAN_ARGS[@]}" pull $IMAGE; then
# fallback to building the image
docker() {
# Preserve "${PODMAN_ARGS[@]}" in the exported function by passing
# them through a single variable, and unpacking them here.
PODMAN_ARGS=(${PODMAN_ARGS})
sudo podman "${PODMAN_ARGS[@]}" "$@" --network=host
}
export -f docker
PODMAN_ARGS="${PODMAN_ARGS[@]}" "$REPO_ROOT"/ci/container/build-image.sh
unset -f docker
fi

if [ "${REBUILD_IMAGE:-false}" = true ]; then
"$REPO_ROOT"/ci/container/build-image.sh
elif $PODMAN_CMD "${ARGS[@]}" "${PODMAN_ARGS[@]}" image exists "$IMAGE"; then
$PODMAN_CMD "${ARGS[@]}" pull "$IMAGE"
else
"$REPO_ROOT"/ci/container/build-image.sh
fi
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in my opinion the previous behavior was much less surprising: whenever you run container-run.sh, you'd get the latest image (whether you download it or build it) without having to think twice.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually you're right, there was a small logic error. I fixed it now.

ARGS=()
DEVENV=false
fi
PODMAN_CMD="sudo podman"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

out of curiosity, did you figure out why sudo is required? I guess --privileged requires it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah it's required to access the hoststorage drive.


if findmnt /hoststorage >/dev/null; then
PODMAN_ARGS=(--root /hoststorage/podman-root)
# Detect if we're running in a Devenv environment
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

discussed offline, but FTR: I think it would be good to have a script that's independent of the devenv, and have a devenv-specific wrapper that calls said script. That would separate the concerns better (running the container vs developing in the devenv incl. image GC etc)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey I agree, but would prefer to save that for another PR.

other_args="--pids-limit=-1 -i $tty_arg --log-driver=none --rm --privileged --network=host --cgroupns=host"

# option to pass in another shell if desired
if [ $# -eq 0 ]; then
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to make sure I understand: if no arg is set, then it drops you into an interactive shell with USHELL (defaulting to bash), and OTOH if some args are passed it interprets them as a command and executes said command, correct?

Copy link
Contributor Author

@cgundy cgundy Jan 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, the behavior is this:

  • If no command is passed in CMD will be set to the env var $USHELL. If $USHELL is not set, it will default to /usr/bin/bash
  • If a command is passed in it will use that command.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants