Configurable strategy to control GraalVM build image pulling

[yrodiere]

Description

When you don't have GraalVM in the path, but have podman/docker installed on your system, Quarkus will default to running the native GraalVM build in a container on podman/docker. Which is great.

One point of pain, though, is that the container images used for the build are floating images: the tags get updated every week to point to a "fresh" image. That's good for security, but for development environments it's a bit overkill and implies frequent re-downloads that may not be acceptable on non-fiber connections.

It could be a good idea to allow configuring the GraalVM build image pulling strategy, e.g. -Dquarkus.native.container-build.pull=always|missing? That way one would be able to set the environment variable QUARKUS_NATIVE_CONTAINER_BUILD_PULL=missing on one's development environment and they would only download a new image when Quarkus switches to a new tag of the image.

See also https://groups.google.com/d/msgid/quarkus-dev/CAKW6fifUP93da%3DZs%2BfqpxtQ6C3yrA5DcdK8OF69AcDirUFh-fA%40mail.gmail.com?utm_medium=email&utm_source=footer

Implementation ideas

I may be missing something, but we could just forward the strategy to docker run/podman run through --pull always|missing|never?

There's been talks of using docker-client in the thread on the mailing list, but I must admit I don't see how that's related to this issue.

[yrodiere]

cc @cescoffier

[cescoffier]

@yrodiere Wow... I didn't know that docker run had a pull option. Podman has different values (newer). But we can at least use the one they have in common:

"always"|"missing"|"never"

[cescoffier]

(PS: that would avoid having to re-implement the logic using a docker/podman client).

[yrodiere]

I just noticed docker run defaults to --pull missing and wondered what was going on... It turns out we don't force docker run --pull always, but we do an explicit pull before the run for whatever reason:

quarkus/core/deployment/src/main/java/io/quarkus/deployment/pkg/steps/NativeImageBuildContainerRunner.java

Lines 51 to 64 in f2f24be

	log.info("Checking image status " + effectiveBuilderImage);
	Process pullProcess = null;
	try {
	final ProcessBuilder pb = new ProcessBuilder(
	Arrays.asList(containerRuntime.getExecutableName(), "pull", effectiveBuilderImage));
	pullProcess = ProcessUtil.launchProcess(pb, processInheritIODisabled);
	pullProcess.waitFor();
	} catch (IOException | InterruptedException e) {
	throw new RuntimeException("Failed to pull builder image " + effectiveBuilderImage, e);
	} finally {
	if (pullProcess != null) {
	pullProcess.destroy();
	}
	}

Unfortunately docker pull doesn't have an equivalent to docker run --pull always|missing, so we would only be able to keep the docker pull when quarkus.native.container-build.pull is set to always, and skip it when it's missing/never...
Which makes sense to me, but I suppose there's a reason we have a separate docker pull in the first place?

[cescoffier]

The pull was there to pull the latest image (the one with less CVEs).

[yrodiere]

The pull was there to pull the latest image (the one with less CVEs).

Ah, in that case simply using docker run --pull always would work just as well. Good!

[yrodiere]

Apparently there's another reason to do an explicit docker pull related to feedback:

quarkus/core/deployment/src/main/java/io/quarkus/deployment/pkg/steps/NativeImageBuildContainerRunner.java

Lines 47 to 50 in 9aaa021

	// we pull the docker image in order to give users an indication of which step the process is at
	// it's not strictly necessary we do this, however if we don't the subsequent version command
	// will appear to block and no output will be shown
	String effectiveBuilderImage = nativeConfig.getEffectiveBuilderImage();

I'll try to find an alternative to docker run --pull.