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
>>
>>

Reply via email to