cqfd: add support for the 'docker' option

[gportay]

This adds the option docker= in .cqfdrc to set the docker binary. It
allows to run the client using sudo(8) or to select the docker binary
(docker, podman).

[deribaucourt]

You could add a test for this feature. It could pass a dummy command as docker, and check that it was executed.

[gportay]

I wonder if I should also add CQFD_DOCKER variable.

[deribaucourt]

Sounds great, maybe even better than a docker option? We can expect users to have a custom docker installation, so they want to pass it through the variable. Passing it through the configuration file doesn't make a whole lot of sense with the many extra_run/build_args options we already have? A configuration would be useful if we want to distinguish which command to use per flavors or project, but it doesn't seem to be the use case you are addressing.

[deribaucourt]

Since the use case rather depends on the user's docker installation than the cqfd project, I think it would be best if this feature was an environment variable rather than in the project file.

[gportay]

In fact, I like both: environment CQFD_DOCKER and property docker=.

Also, prepending sudo to the docker command could be easy with that change:

diff --git a/cqfd b/cqfd
index 6d4a4ab..9748afd 100755
--- a/cqfd
+++ b/cqfd
@@ -27,6 +27,7 @@ cqfd_user='builder'
 cqfd_user_home='/home/builder'
 cqfd_user_cwd="$cqfd_user_home/src"
 cqfd_shell=${CQFD_SHELL:-/bin/bash}
+cqfd_docker=('docker')
 cqfd_docker_gid="${CQFD_DOCKER_GID:-0}"
 
 ## usage() - print usage on stdout
@@ -166,14 +167,14 @@ docker_build() {
 		args+=("$project_build_context" -f "$dockerfile")
 	fi
 
-	debug executing: docker build "${args[@]}"
-	docker build "${args[@]}"
+	debug executing: "${cqfd_docker[@]}" build "${args[@]}"
+	"${cqfd_docker[@]}" build "${args[@]}"
 }
 
 # image_exists_locally(): checks if image exists in the local image store
 # arg$1: the image name to check
 image_exists_locally() {
-	docker image inspect "$1" &> /dev/null
+	"${cqfd_docker[@]}" image inspect "$1" &> /dev/null
 }
 
 # docker_run() - run command in configured container
@@ -197,7 +198,7 @@ docker_run() {
 	if ! image_exists_locally "$docker_img_name"; then
 		# If custom image name is used, try to pull it before dying
 		if [ "$project_custom_img_name" ]; then
-			if ! docker pull "$docker_img_name" >& /dev/null; then
+			if ! "${cqfd_docker[@]}" pull "$docker_img_name" >& /dev/null; then
 				die "Custom image couldn't be pulled, please build/upload it first"
 			fi
 		else
@@ -255,6 +256,11 @@ docker_run() {
 		fi
 	fi
 
+	# Use sudo if user is not in the docker group
+	if [ "$cqfd_docker_gid" -eq 0 ]; then
+		cqfd_docker=(sudo "${cqfd_docker[@]}")
+	fi
+
 	# Display a warning message if using no more supported options
 	if [ -n "$CQFD_EXTRA_VOLUMES" ]; then
 		die 'Warning: CQFD_EXTRA_VOLUMES is no more supported, use
@@ -332,8 +338,8 @@ docker_run() {
 
 	args+=("$docker_img_name" cqfd_launch "$1")
 
-	debug executing: docker run "${args[@]}"
-	docker run "${args[@]}"
+	debug executing: "${cqfd_docker[@]}" run "${args[@]}"
+	"${cqfd_docker[@]}" run "${args[@]}"
 }
 
 # make_archive(): Create a release package.

[florentsfl]

While investigating the Docker rootless issue, I also tried podman and it seems to suffer from the same issues, that is to say file permissions errors etc.

For now it seems that cqfd is too tightly coupled to docker rootful so i would postpone this feature until cqfd is compatible with podman

[gportay]

For now it seems that cqfd is too tightly coupled to docker rootful so i would postpone this feature until cqfd is compatible with podman

Indeed. That change is useful to substitute the docker command by podman (or any other docker-like application).

We need to find out the proper options to run cqfd with a rootless setup first.