namedTaskExecutionGraphEntryPointsLists similar to defaultTasks

Old Forum
1

Clearly the name is not being recommended, but hopefully it helps set the context for the idea.

Right now there are basically 3 ways for a user to cause tasks to get executed.

  1. Invoke a single task from the command line 2. Invoke no tasks from the command line (which causes defaultTasks to be utilized) 3. Invoke multiple tasks from the command line

Let’s ignore the case of the single task specified (either explicitly or by defaultTasks), as the ordering of tasks will be handled strictly by dependsOn() and mustRunAfter() relationships.

For the case of multiple tasks specified, they are still constrained by dependsOn() and mustRunAfter() relationships, but Gradle “enters” the task graph for each explicitly named task in the order they are specified on the command line or in the defaultTasks list.

dependsOn() and mustRunAfter() are relationships between tasks.

Invoking multiple tasks explicitly from the command line or using just defaultTasks does not affect the relationships between any tasks, but it does provide a means of passing an ordered list of task names to use to start traversal of the task execution graph.

What is currently missing is the ability to provide a “named” list of tasks to sequentially enter the task graph at. defaultTasks is essentially the “unnamed” list of tasks to sequentially enter the task graph at.

namedTaskList myNotify, ['build', 'notifyBuilt', 'analyze', 'notifyAnalyzed']
namedTaskLists(['ftpTransmit': ['bundle', 'ftp'], 'sshTransmit': ['bundle', 'encrypt', 'ssh']])

These would not create actual tasks, but just a way to reference a list of tasks for convenience at the command line, or via an IDE tooling invocation.

So running gradle tasks would result in something similar to the below.

Default tasks: a, b, c
myNotify tasks: build, notifyBuilt, analyze, notifyAnalyzed
ftpTransmit tasks: bundle, ftp
sshTransmit tasks: bundle, encrypt, ssh

One question would be whether namedTaskLists with the same name as regular tasks for a project would take precedence (hide them essentially) or if it would be an error to have a namedTaskList with the same name as a task. Also, maybe these aliases are multi-project wide and you cannot have different “bindings” for different subprojects (or the last set one with the same name overwrites any previous list).

-Spencer

2

I think this is similar to our plan for “build types”. Something like… https://github.com/gradle/gradle/blob/master/build.gradle#L27

Plan is to formalise this as part of this story: https://github.com/gradle/gradle/blob/32dc5e85da4ef042082d00cd6c869736f1b2ad64/design-docs/lazy-configuration.md#allow-the-project-version-to-be-determined-early-in-the-build-configuration

Does this align with your idea?

3

Thanks for the pointer, I had not thought to look in the lazy-initialization design document for something related to my idea.

Build types is definitely very closely aligned, plus much more ambitious.

The main potential difference is that the build types run list looks like it might apply only to the tasks within the implicit project, instead of all tasks with the same name across all projects within a multi-project build.

I’m not clear yet on how the build types are intended to work across projects in a multi-project build.

Edit: After looking at BuildTypes.groovy in buildSrc, I see how it is directly manipulating startParameters.taskNames, so that implementation definitely allows for the behavior desired.

-Spencer