bootBuildImage runs forever when a custom image name is used and the version contains an illegal character

[mxab]

I noticed that when I have for example a + in the version the build fails, which is ok I guess. But when I have a + in the version and set a custom image name e.g:

// version that contains a '+'
version="1.6.0-dev.2.uncommitted+wip.foo.c75795d"

and

tasks.named("bootBuildImage") {
    imageName = "registry.example.com/example/example-app:${version}"
}

the build image job runs forever.

See this example app here:
https://github.com/mxab/spring-boot-illegal-version-custom-name-problem

[scottfrederick]

Thanks for the example app.

I noticed that when I have for example a + in the version the build fails, which is ok I guess.

The Spring Boot Gradle plugin and the Paketo CNB builder that bootBuildImage invokes by default use the same Docker image reference validation rules, which are codified by Docker and do not allow a + in an image tag.

The bootBuildImage task should fail with an error similar to this when provided this image name:

Execution failed for task ':bootBuildImage'.
> Unable to parse image reference "demo:1.6.0-dev.2.uncommitted+wip.foo.c75795d". Image reference must be in the form '[domainHost:port/][path/]name[:tag][@digest]', with 'path' and 'name' containing only [a-z0-9][.][_][-]

If you provide the same image reference to the pack CLI, it will fail with a similar message:

ERROR: failed to build: invalid image name 'demo:1.6.0-dev.2.uncommitted+wip.foo.c75795d': could not parse reference: demo:1.6.0-dev.2.uncommitted+wip.foo.c75795d

the build image job runs forever

I was able to re-create this, but not consistently. When it does appear to hang, Gradle is repeatedly acquiring and releasing a lock on the daemon. Changing imageName from registry.example.com/example/example-app:${version} to registry.example.com/example/demo:${version} seems to eliminate the hanging. We'll keep digging on that.

[mxab]

Yes I saw the same acquiring/releasing lock message when I run it with --debug.

As context to the version, this was generated by the nebula release plugin, but you can turn of this +my-metadata-info... off
via:

release.sanitizeVersion=true

https://github.com/nebula-plugins/nebula-release-plugin#sanitize-versions

in case someone has the same issue

[scottfrederick]

I've narrowed this down to a complex regular expression that Spring Boot uses to parse an image reference to make sure it's valid before passing it off to downstream APIs. Providing an image reference registry.example.com/example/example-app:1.6.0-dev.2.uncommitted+wip.foo.c75795d to ImageReference#of(String) in a unit test will cause the matcher.matches() call to process for 20+ minutes before returning a false return value. Editing the image reference in small ways like reducing the size of the tag or replacing one of the instances of example in the path reduces the time spent in matcher.matches().

Marking this as a bug in 2.3.x but it may take some time to isolate the interaction between this input and the regular expression.

[SimSonic]

I've just spent about 6 hrs looking why

gradle --no-daemon --build-cache --info bootBuildImage --imageName=$BACKEND_IMAGE

is just silently freezes.

Also found release/lock loop messages but not the problem itself.

Resolved just thanksfully to this issue!

[philwebb]

We discussed this again and think it's a good idea to review the regex patterns. If we can't improve them then we're going to do the work in a thread and add a timeout.