First-class support for lifecycle tasks

[lptr]

Gradle has had the notion of "lifecycle" tasks, i.e. tasks that represent some point in the lifecycle of the build, such as assemble, or check.

These tasks are currently defined implicitly, by not having any inputs, outputs or actions, only dependencies. Build scans show them as such if these properties are met.

The problem with this is that it's easy to confuse lifecycle tasks with tasks that the author simply forgot to add any inputs/outputs to. There is also this anti-pattern that results in an unintentional "lifecycle" task:

task alma {
    file("alma.txt").copyTo(file("bela.txt"))
}

The problem above is (obviously, duh!) that the action is executed during configuration time, without declaring any of the inputs/outputs.

We could avoid a bunch of these problems if lifecycle tasks were required to be of a specific LifecycleTask type. This type could be final, without a task action. We could show deprecation warnings for implicit lifecycle tasks for a long time, then remove support after a while.

---

cc: @gradle/build-cache

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. If you're interested in how we try to keep the backlog in a healthy state, please read our blog post on how we refine our backlog. If you feel this is something you could contribute, please have a look at our Contributor Guide. Thank you for your contribution.

[wolfs]

We still want to do this!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. If you're interested in how we try to keep the backlog in a healthy state, please read our blog post on how we refine our backlog. If you feel this is something you could contribute, please have a look at our Contributor Guide. Thank you for your contribution.

[ribafish]

I believe there's some common misunderstandings regarding lifecycle tasks (as confirmed by conversations on slack here and here), so having to explicitly specify a LifecycleTask type seems like a good way to clear up some confusions, I also think showing (deprecation) warnings for implicit lifecycle tasks seems like a nice migration solution 👍 .

I'd just add that currently, lifecycle tasks are implicitly defined if a task has no action, but it can have inputs and outputs, which might be surprising (the outputs).