Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disallow actions that should not happen inside a task's configuration #27030

Open
hungvietnguyen opened this issue Nov 13, 2023 · 1 comment
Open
Labels
a:feature A new functionality @configuration-cache in:configuration-model lazy api, domain object container in:writing-tasks task option re:comprehensibility reasonable errors and warnings, clear dsl, mental overload

Comments

@hungvietnguyen
Copy link

Current Behavior

Currently, registering a task in another task's configuration will fail with:

> DefaultTaskContainer#register(String, Action) on task set cannot be executed in the current context.

However, as of version 8.4, Gradle still allows the following actions to take place inside a task's configuration:

  • Creating a Configuration
  • Registering a BuildService
  • Registering a TransformAction
  • (and maybe more)

Expected Behavior

It would be great if Gradle could clarify what actions are okay to run inside a task's configuration and what actions are not, and fail the build for actions that should not be run inside a task's configuration (similar to the error for registering a task above).

Context (optional)

On one hand, performing the above actions in the task configuration has these benefits:

  • It is good for build performance because if the task is not scheduled for execution, that work will be avoided.
  • Even if it doesn't actually improve build performance, it's tempting to do that in the spirits of making everything lazy, and the fact the Gradle currently doesn't disallow them suggests that they're somehow okay to do.
  • It improves code organization. For example, in AGP, the L8DexDesguarLibTask's desugaredDesugarLibJar property is configured only under a certain condition, and its value is obtained through a transform, so it's easier/cleaner to register the transform where it's needed. (It's similar to a good software practice where a local variable should be declared close to where it is used).

On the other hand, performing these actions in the task configuration might cause issues with configuration-on-demand, configuration cache, composite builds, etc. Gradle users/plugin authors are unlikely to be aware of these issues, which result in latent, hard-to-debug problems.

Steps to Reproduce

(See above)

Gradle version

8.4

Build scan URL (optional)

No response

Your Environment (optional)

No response

@cobexer cobexer added a:feature A new functionality in:writing-tasks task option re:comprehensibility reasonable errors and warnings, clear dsl, mental overload and removed a:bug to-triage labels Nov 14, 2023
@cobexer
Copy link
Member

cobexer commented Nov 14, 2023

Thank you for your interest in Gradle!

This feature request is in the backlog of the relevant team, but this area of Gradle is currently not in focus. It might take a while before it gets implemented.


There should indeed be clear documentation aligned with code behavior regarding allowed and disallowed build configuration actions inside a task configuration.

@mlopatkin mlopatkin added in:configuration-model lazy api, domain object container @configuration-cache labels Dec 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a:feature A new functionality @configuration-cache in:configuration-model lazy api, domain object container in:writing-tasks task option re:comprehensibility reasonable errors and warnings, clear dsl, mental overload
Projects
None yet
Development

No branches or pull requests

3 participants