Hi,
and it is: ~/.gradle/.tmp
See the "." before the ".tmp"! This stupid period makes it harder to
find that issue because it hides itsself from dircetory listing. I am
sure the Gradle people want to hurt us!
Uwe
Am 21.03.2025 um 15:42 schrieb Dawid Weiss:
I'll take a look at it later, can't do it right now.
On Fri, Mar 21, 2025 at 3:41 PM Dawid Weiss <dawid.we...@gmail.com> wrote:
I also wonder why the current hack we have in place (LUCENE-9471)
doesn't work... or maybe I do know - this seems like it's
resolving to project-relative path instead of user home-relative path.
configure(rootProject) {
gradle.buildFinished {
rootProject.delete fileTree(".gradle/tmp").matching {
include "gradle-worker-classpath*"
}
}
}
D.
On Fri, Mar 21, 2025 at 3:34 PM Robert Muir <rcm...@gmail.com> wrote:
is it https://github.com/gradle/gradle/issues/12020 ?
On Fri, Mar 21, 2025 at 10:07 AM Uwe Schindler
<u...@thetaphi.de> wrote:
>
> Hi,
>
> I found the reason why builds on the Jenkins machine
(policeman) get
> slower and slower especially on MacOS and Windows. The
reason is also
> affecting Linux, but depending on filesystem it does not
slow down too
> much. ZFS was fine, EXT4 is slow.
>
> Basically what happens: Looks like for each runner (and
there are many),
> Gradle produces a file in ~/.gradle/.tmp with name
> gradle-worker-classpathXXXXXXXX (with XXX some random hash).
It does not
> create any subdirectories all those files are accumulating
in that
> folder and are never cleaned up. On the MacOS node, I tried
a "rm -rf
> ~/.gradle/.tmp" hich never ended and finaly ran out of
memory!!!!! An ls
> in the directory also takes hours.
>
> The effect of that number of files is: each update of the
directory
> takes forever, so Gradle wants to create a new directory,
but depending
> of filesystem (APFS) also creating a file needs to insert
the directory
> entry and that takes forever. We should open a bug report at
Gradle
> about this, I think this is insane!
>
> On Windows the same happens, but I was able to move the
folder to trash
> and started an async trashing cycle which took half an hour.
>
> I am about to create a Jenkins addition that nukes the whole
> ~/.gradle/.tmp file before each build on all our Jenkins
nodes to
> prevent this from happening again. You may also be advised
to add a
> cronjob in your user directory to nuke the gradle folder (I
have the
> feeling from time to time, you should trash it completely).
The .gradle
> folder collects all bullshit from each previously used
Gradle version.
> On The Jenkins node it was 10 Gigabytes!
>
> Uwe
>
> --
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
--
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail:u...@thetaphi.de
