You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While executing the release task, I noticed 2 things:
most dependent tasks are executed twice
I set an ext property based on gradle.startParameter.taskNames.contains('release'), but this property gets lost during the release task because it runs in a new context with a new startParameter
So my question: is there a specific reason why the release task has type GradleBuild i.s.o. being a plain task that depends on other tasks?
Ivo
The text was updated successfully, but these errors were encountered:
Yes. Initially I wanted user's to be able to define the release process and just provide A. a good default, B. helpful tasks that the user can use if they want to define the process completely.
The issue is that the configuration for tasks is done after the tasks and tree is defined, so that's not possible atm.
The other reason is that the "depends" option doesn't guarantee order. It does in the base case here because each task would only depend on a single task, but if the user plugged in their own dependencies those could get executed before the other tasks - since gradle has it's own logic to determine which task should be executed first. Using the GradleBuild type was/is the only way I know of that can absolutely guarantee order.
Hi,
While executing the release task, I noticed 2 things:
gradle.startParameter.taskNames.contains('release')
, but this property gets lost during the release task because it runs in a new context with a new startParameterSo my question: is there a specific reason why the release task has type GradleBuild i.s.o. being a plain task that depends on other tasks?
Ivo
The text was updated successfully, but these errors were encountered: