Share build cache configuration instead of build cache service #4231
Conversation
4bb596c to
019d1fb
Compare
c68232a to
07c40ba
Compare
31a1fde to
8591878
Compare
Sharing the service causes problems when they are shut down - sometimes the root service is shut down even if one of the included builds is still running and using it. #4216
8591878 to
a6350ce
Compare
It is possible to have more than one DirectoryBuildCache service using the same target directory.
699e009 to
3002a18
Compare
| """ | ||
|
|
||
| expect: | ||
| succeeds '--parallel' |
There was a problem hiding this comment.
you don't need --parallel as the tasks for included builds are run in parallel anyway.
There was a problem hiding this comment.
Good catch, @adammurdoch. Removed.
|
This seems like the wrong solution to me. I think we should fix the lifecycling instead. For example, this would complicate a solution for pre-emptively opening connections to the remote cache to amortize the connection cost. |
| and: | ||
| def finalizeOps = operations.all(FinalizeBuildCacheConfigurationBuildOperationType) | ||
| finalizeOps.size() == 2 | ||
| finalizeOps.size() == 5 |
There was a problem hiding this comment.
This is a break for build scans.
We either need to roll this back (e.g. don't fire this event for non root builds), or we have to update build scans to ignore these events.
|
I've just realised that I think we should just not fire the root buildFinished until the other builds have completed, as per #4199. |
|
Closed in favor of #4249 |
Sharing the service causes problems when they are shut down - sometimes
the root service is shut down even if one of the included builds is
still running and using it.
This provides a fix for #4216.