This message was deleted.

you could add an additional action for all publishing tasks that would log the GAV to console

tasks.withType<AbstractPublishToMaven>().configureEach {
    val publicationGAV = provider { publication?.run { "$group:$artifactId:$version" } }
    doLast("log publication GAV") {
        if (publicationGAV.isPresent) {
            logger.lifecycle("[task: ${path}] ${publicationGAV.get()}")
        }
    }
}

That could be amended to write the GAV to a file too.

actually why not just look at the publications extension directly?

tasks.register("listPublications") {
    doLast {
        for (publication in publishing.publications.filterIsInstance<MavenPublication>()) {
            println("${publication.groupId}:${publication.artifactId}:${publication.version}")
        }
    }
}

Ah,

publications

, I was trying

configurations

and looking to access the

runtimeElements

and

archives

, and not able to get all the right information. Though using

doLast

might also have helped. But the publishToMavenLocal works just as nicely and won't require gradle files to be modified (will be turning this into a github action to help call promote on the artifact hosting tool and allow us to switch the tool used without needing to rework everyones gradle file. Which is perfect. Many thanks for the pointers. I presume

filterIsInstance

is kotlin? I had to switch the code to the following as I'm using groovy but I presume this is the expected way to achieve the same (my groovy is rusty):

tasks.register("listPublications") {
    doLast {
        for (publication in publishing.publications.findAll{it instanceof MavenPublication}) {
            println("${publication.groupId}:${publication.artifactId}:${publication.version}")
        }
    }
}

sounds like a good plan!

will be turning this into a github action to help call promote on the artifact hosting tool and allow us to switch the tool used without needing to rework everyones gradle file

Just curious: did you consider turning it into a Gradle plugin instead? Then you wouldn’t need to pipe/grep stdout, and you could write it in Kotlin (or Java or Groovy, whatever works best)

We'll have npm, python, generic, and maven artifacts, so having an action to handle this cleanly for projects without needing to expose the backing service too much is probably better for this particular situation. If it was just one or two types then a native plugin/library probably would make sense

ah yeah, makes sense