与许多开发人员共享Gradle用户主页的任何缺点? [英] Any Drawbacks of Sharing the Gradle User Home with Many Developers?

查看:76
本文介绍了与许多开发人员共享Gradle用户主页的任何缺点?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在同一文件系统上的多个开发人员之间共享Gradle用户主目录是否有缺点?

Are there any drawbacks of sharing the Gradle user home amongst multiple developers on the same filesystem?

我们的目标是使用本地Gradle缓存节省磁盘空间. Gradle用户指南建议该缓存对于并发访问是安全的.目前似乎没有任何方法可以独立于Gradle用户主目录配置缓存位置,因此从本质上讲,这个问题归结为共享Gradle用户主目录(默认为~/.gradle/).通过快速测试,我们可以验证同一用户的多个并发进程确实确实可以在单个Gradle用户家庭中正常工作.

Our goal is to save disk space with the local Gradle cache. The Gradle user guide suggests that the cache is safe for concurrent access. There doesn’t currently seem to be any way to configure the cache location independently from the Gradle user home, so essentially the question boils down to sharing the Gradle user home (defaults to ~/.gradle/). In a quick test we could verify that multiple concurrent processes of the same user do indeed work flawlessly with a single Gradle user home.

但是多个用户可能有任何问题吗?我可以想象权限问题可能会成为问题.有人对这种设置有经验吗? Gradle用户主目录中是否有不应共享的文件?

But could there be any problems with multiple users? I could imagine that permission issues might become a problem. Does anyone have any experience with such a setup? Are there any files in the Gradle user home which shouldn’t be shared?

很明显,使用共享的用户主目录不再可能进行某些特定于用户的配置(例如个性化的初始化脚本 gradle.properties ) .对于使用本地Gradle缓存节省磁盘空间,您是否有更好的建议?这样的建议可能是以某种方式自动修剪每个用户的缓存,如在此问题中提出的那样.

It’s clear that certain user-specific configurations wouldn’t be possible anymore with a shared user home (like personalized init scripts or gradle.properties). Do you perhaps have any better suggestion for saving disk space with the local Gradle cache? Such a suggestion could be to somehow automatically prune the cache of each user as asked in this SO question.

我们使用Gradle处理更大的二进制文件(当前每个〜500M并正在增长).这包括从其他大型二进制工件中构建它们作为输入依赖项.我们将构建工件存储在Artifactory中;上传和下载进行得很顺利.但是,由于我们每周大约有50个开发人员在混合和匹配许多文件,因此每个开发人员的本地Gradle缓存都增长很快.当所有开发人员都在同一个文件系统上工作时,我们正在考虑为所有开发人员共享一个Gradle缓存,以节省磁盘空间.

We use Gradle for working with somewhat bigger binary files (currently ~500M each and growing). This includes building them from other big binary artifacts as input dependencies. We store our build artifacts in Artifactory; uploading and downloading goes pretty smoothly. However, since we have about 50 developers who are mixing and matching many files every week, the local Gradle cache of each developer grows rather quickly. As all developers work on the same filesystem, we were thinking about having a shared Gradle cache for all developers to save disk space.

推荐答案

我刚刚发现

I have just found this comment by Gradle developer Stefan Oehme wrt. sharing the Gradle user home:

Gradle进程将在无竞争的情况下持有锁(以提高性能).争用是通过进程间通信来宣布的,当将进程隔离在Docker容器中时,该争用将不起作用.

Gradle processes will hold locks if they are uncontended (to gain performance). Contention is announced through inter-process communication, which does not work when the processes are isolated in Docker containers.

更清楚的是,他在后续评论中指出(由我突出显示):

And more clearly he states in a follow-up comment (highlighting by me):

我们可能还没有发现其他问题,因为在计算机之间共享用户家不是我们设计的用例.

换句话说:Gradle目前不正式支持在不同的机器之间共享Gradle用户家,甚至只是其中的缓存部分.

In other words: sharing a Gradle user home or even just the cache part of it across different machines is currently not officially supported by Gradle.

Gradle用户主目录仍然不打算共享,但是,现在至少可以完全复制高速缓存"(参见

The Gradle user home is still not meant to be shared, however, it is now at least "perfectly possible to copy a cache around" (cf. the user guide). Not sure what that means for concurrent access from different hosts; it still provides a basis for more sharing scenarios than were officially supported before.

这篇关于与许多开发人员共享Gradle用户主页的任何缺点?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆