Теоретически, список задач известен только project evaluation, поэтому получить его как бы невозможно. Вам оно зачем?

Есть таска releaseTask, она должна зависеть от тасок publishXToSpaceRepository из каждого субпроекта или рут-проекта.

Тогда можно dependsOn("${subproject.path}/publish..ToSpaceRepository")

allprojects { releaseTask.dependsOn("$path:publishXToSpaceRepository") }

, может?

Например. Но тут мы не пытаемся узнать перечень задач

Спасибо

Это падает, потому что иногда эти задания отсутствуют.

значит нужно распознавать на уровне названий проектов

или всегда делать фиктивную задачу «опубликовать всё», которая будет либо пустой, либо зависеть от нужных в конкретном проекте

А нельзя ли в afterEvaluate ставить зависимость, смотря на конечные списки тасок по всему проекту?

Hi! anyway to ignore that file?app/mirakle_build_file_stub' is not part of the build defined by settings file '/home/jart/Test/TestApk/settings.gradle'. If this is an unrelated build, it must have its own settings file.  NOTE: File to ignore : mirakle_build_file_stub

А pluginManagement в settings.gradle.kts никак не влияет, получается, на buildSrc?

хз, но выполняется он первее

Да я уже сдался, с buildSrc всё равно зависимости от плагинов надо прописывать явно.

а зачем тебе вообще buildSrc?

Ну всё, пошла жара

я делаю так: у меня есть includedBuild dependencies с плагином соотв., в buildSrc в плагинах я делаю id("dependencies") и далее у меня везде есть доступ к версиям зависимостей

т.е. это единственная строковая штука, которую я руками пишу

не, мне было интересно для какой цели тебе надо

afterEvaluate же для текущего проекта. Поэтому даже когда запустится rootPriject.afterEvaluate, то остальные могут ещё быть неготовыми. Как вариант можно в каждом проекте в его afterEvaluate "добавляться к корневому", но это нехорошо, т.к. размазывает конфигурацию. По хорошему, всё, что делает каждый из модулей должно быть понятно по его коду. Например, корневой агрегирует, и логику агрегации нехорошо размазывать по подпроектам.