Recommend don't create the dockerTag${project.version} and dockerPush${project.version} task by default, keep to add it by user self as 0.30.0 version.

[yuanjinyong]

What happened?

In 0.31.0 version, the DockerExtension had chagne
from

    public Set<String> getTags() {
        return tags
    }

to

    public Set<String> getTags() {
        return Sets.union(this.tags, ImmutableSet.of(project.getVersion().toString()))
    }

And this will create two tasks: dockerTag${project.version} and dockerPush${project.version}.
But the project.version value maybe like 'x.y.x-SNAPSHOT' for nightly build, and the corresponding tag is nightly, if run dockerPush task, will also run dockerPush${project.version} cause to push a ${archivesBaseName}:x.y.x-SNAPSHOT tag.

project.tasks["dockerTag${project.version}"].enabled = false
project.tasks["dockerPush${project.version}"].enabled = false

What did you want to happen?

Just keep the default value of tags same with previous version(<0.31.0).
User can add it by self who want these tasks like following:

docker {
    tag project.version, "${dockerUrl}/${project.group}/${archivesBaseName}:${project.version}"
    tag 'latest', "${dockerUrl}/${project.group}/${archivesBaseName}"
    tag project.buildType, "${dockerUrl}/${project.group}/${archivesBaseName}:${project.buildType == 'release' ? project.version : 'nightly'}"
}

[mhuebner]

+1

Same here! Since 0.30.0 also the project.version is tagged and pushed - what I don't want.
Our version also includes a commit id but seems to be overwritten with project.version automatically.

[idkomarov]

Agree with you!
It can be confusing for inexperienced gradle users in my project.
Moreover it's ugly for me as for gradle scripting perfectionist ._.

[ievgen-kapinos]

Please prioritise. This issues blocks us to upgrade plugin version

[tuus-amicus]

Any progress on it?

Faced with that problem today.

We have pipeline which pushes docker image, depending on some code.

Since 0.32.0 it takes project.version without any possible way to override it.

[idkomarov]

Please prioritise. This issues blocks us to upgrade plugin version

What do you want from us when you write "please prioritise"?

[ievgen-kapinos]

@idkomarov See issue description

Just keep the default value of tags same with previous version(<0.31.0).

[tuus-amicus]

As a temporary solution when anyone will need it

using .kts:

tasks {
   named("docker") { 
        doFirst {
            named("dockerTag${project.version}") {
                enabled = false
            }
            named("dockerPush${project.version}") {
                enabled = false
            }
        }
    }
}    

But hope it will be fixed as soon as possible.

[hardboiledphil]

For anyone that ends up with something similar to the following error when building

Docker tag '0.74.0-SNAPSHOT-refs/pull/469156/merge' must have a task name.

We are migrating from Gradle 7 to 8 and on updating the Palantir plugin version we see this when running a PR build on ADO (Azure Dev Ops).

The issue is that the addition of the default tag with the project.version is picking up a string that contains '/' which along with ':' is not allowed in the task name generation. So the error is misleading but ultimately ${project.version} is not under the control of the developer and the plugin will always fail.

I could understand generating a default tag if no tag existed but in this scenario the default is not required but the fact it is put there causes the build to fail. The suggested workarounds above I don't think will work as the issue is not that the default tag exists and the task can be disabled but that it can never even be created due to the unusual branch name and name generation logic.

Be interested to know if Github PR builds use the same technique of using a temporary merge branch and as such would have the same issue?