Skip to content

Conversation

@vkryachko
Copy link
Member

Fixes #12

@vkryachko
Copy link
Member Author

/retest

@vkryachko
Copy link
Member Author

/retest

Copy link
Contributor

@ashwinraghav ashwinraghav left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

;tldr I think we should ship this, and keep an eye out.

The risks I see are that we have a cache that does not have a strict notion of the fact that it is caching maven artifacts, which might lead to some unexpected caveats in the future.

One area that bjornick@ mentioned that is worth exploring is to mount a shared directory for the maven cache with individual containers each having their own gradle cache. Something worth exploring if this does not work out reasonably.

@vkryachko
Copy link
Member Author

SG

One area that bjornick@ mentioned that is worth exploring is to mount a shared directory for the maven cache with individual containers each having their own gradle cache. Something worth exploring if this does not work out reasonably.

This is exactly the setup we have today and it still causes lock contention because multiple gradle processes try to populate the cache as they run. Also this approach relies on gradle's current cache directory layout which is not documented and afaik is not guaranteed to be stable.

@vkryachko vkryachko merged commit a4357b8 into master Sep 17, 2018
@vkryachko vkryachko deleted the vk.maven-proxy branch September 21, 2018 20:14
ashwinraghav added a commit that referenced this pull request Sep 28, 2018
@firebase firebase locked and limited conversation to collaborators Oct 14, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

CI fails on gradle cache lock timeout.

3 participants