This message was deleted.
# plugin-developments
Slackbot
10/13/2022, 12:19 AMThis message was deleted.
c
Chris Lee
10/13/2022, 12:42 AMCan the task be configured with proper dependencies such that Gradle can manage the parallelism?
b
Ben Blechman
10/13/2022, 12:53 AMThe dependencies are configured. The task in question is an Android DeviceProviderInstrumentTestTask. What we are doing is adding a logcat listener before the task, and removing after the task. So there is this external resource that is somewhat outside of gradle. We need only one emulator logcat listener added at a time, as we want only the logcat generated from this test task. There may be some alternative implementation, but I am trying to make config cache compliant with the minimum necessary changes. Totally open to suggestions.
Ben Blechman
10/13/2022, 1:01 AMI was hopeful that a BuildServices maxParallelUsages would work for all of the task’s actions, but that’s not the case. So in that sense it feels like I am configuring so gradle can manage the parallelism, but it ’s not working as expected.
v
Vampire
10/13/2022, 8:12 AMIf that would really be the case it is indeed a bug.
All actions should be affected, also
doFirstusesServiceb
Ben Blechman
10/13/2022, 8:21 PMYes, we do declare usesService for this task. I’ll try to prepare a MCVE. I don’t see the problem in a small test project we use for plugin development, but it does show up in our large project, so may require some work to repro.
I considered trying to change this doFirst action to a task, and setup dependencies and finalizers such that ordering would be explicitly enforced. A coworker said he ran into a gradle bug in the past such that task finalizers are not always respected across modules, so he thought this wouldn’t work either. Still considering this idea though.
Ben Blechman
10/21/2022, 6:49 PMI realized after trying to reproduce this more, that I was just misunderstanding our logs and how gradle works. The issue was not that multiple doFirst actions were running in parallel, it’s just that there is no guarantee about ordering. doFirst actions run independently from other task actions. So multiple doFirst actions from different tasks can run, and then other task actions will run, even if only one is allowed to run at a time. It would be convenient to have concept of chained actions that must run together, but it doesn’t work that way.
So I don’t think there is a gradle bug here, just me not understanding how gradle works, and inheriting some code that had a hacky work around to avoid how gradle works wrt to doFirst actions and the rest of the actions for that task.
I was able to refactor all of this code to avoid the issue by moving more of the code to a build service so that the service is responsible for listening on the external emulator logcat resource, rather than trying to have tasks synchronize the adding and removing of listeners. There was another unrelated blocker why it wasn’t implemented that way in the first place, but I found a way around it.
Thanks for the responses.
👌 1
👍 1