This message was deleted.

Same as for other lifecycle tasks. If you run

build

it only runs in the projects of the main build and in the included builds only the absolutely necessary tasks are run. (Usually compiling and building the jar) So if you want the other semantic, make the lifecycle task of the root build depend on the respective lifecycle tasks in the included builds.

What is the right way to do that without causing issues with cross project configuration and eager task creation? In this case there isn’t even a root project task with a matching name, sort of a feature rather than an issue IMO. Thinking what I may do is just do a dynamic job on the CI pipeline that only gets included when changes to the gradle directory are detected. Run the included project directly in that case so the lifecycle invocation behavior just works on it again.

Didn't fully get it, but if it works for you, why not. :-) How to do it depends on many factors. You could ensure every project has the task but just might not have work, or you could make that task a specific type for which you could filter, ...

right. last I checked the withType caused eager creation but its been a bit since I've had a look. Honestly thinking i'll just tackle it with the dynamic CI config. Then I am not trying to bend gradle into doing something it really really doesn't want to do off the shelf.

withType

only eagerly creates if you directly give it a configure action. As long as you only get the tasks by type or use

configureEach

, you are fine regarding task configuration avoidance.

ahh ok, today I learned. so maybe worth an attempt to wire it in