On 17 January 2018 at 08:34, Yoann Rodiere wrote:
> Thanks for trying :) We might try to improve the Maven plugins in question,
> but as you said we already spent quite some time on infrastructure...
>
> That being said, if we are ever to follow-up on this caching idea, Gunnar's
> idea of a local
Thanks for trying :) We might try to improve the Maven plugins in question,
but as you said we already spent quite some time on infrastructure...
That being said, if we are ever to follow-up on this caching idea, Gunnar's
idea of a local Nexus got me thinking... Was your change only about
performa
Version F27v17 of the slaves is running now, with NFS drive removed.
sorry for the experiment :)
Thanks
Sanne
On 16 January 2018 at 21:51, Sanne Grinovero wrote:
> On 16 January 2018 at 21:33, Steve Ebersole wrote:
>> well Gradle is used in CI environments all over the place, so it must work.
On 16 January 2018 at 21:33, Steve Ebersole wrote:
> well Gradle is used in CI environments all over the place, so it must work.
> But I think we need some different configurations in the Gradle command
> used. For example, it is highly suggested that the Gradle daemon be
> disabled in CI but I'm
well Gradle is used in CI environments all over the place, so it must
work. But I think we need some different configurations in the Gradle
command used. For example, it is highly suggested that the Gradle daemon
be disabled in CI but I'm not sure all of our jobs actually do that. I'll
look into
Yes I did it for Gradle too, sorry. The `/efs-maven-artifacts` is the
guilty mount point.
I don't know any quick solutions for the various concerns you all
raised, so I'll roll this back tonight.
It's good to know that it's not too hard to have a shared FS between
these machines; needs better pla
2018-01-15 11:54 GMT+01:00 Yoann Rodiere :
> > We should reconfigure those to not "install" - that's actually a bad
> > habit, legacy from Maven 2 times - people nowadays recommend using
> > "mvn clean verify", especially on CI environments.
>
> I could not agree more, that would be cleaner, but t
Did you happen to do the same for Gradle caches?
Some jobs are failing:
* What went wrong:
Could not resolve all dependencies for configuration
':buildSrc:runtimeClasspath'.
> Timeout waiting to lock artifact cache
> (/efs-maven-artifacts/.gradle/caches/modules-2). It is currently in use by
>
> We should reconfigure those to not "install" - that's actually a bad
> habit, legacy from Maven 2 times - people nowadays recommend using
> "mvn clean verify", especially on CI environments.
I could not agree more, that would be cleaner, but that's not possible. And
believe me, I tried hard. Las
On 15 January 2018 at 08:42, Yoann Rodiere wrote:
> Thanks Sanne !
>
> I have one question...
>
>> Please never rely on this as "storage": it's just meant as cache and
>> we reserve the right to wipe it all out at any time.
>
> I gather you say that so that we don't try to "release" artifacts into
Thanks Sanne !
I have one question...
> Please never rely on this as "storage": it's just meant as cache and
> we reserve the right to wipe it all out at any time.
I gather you say that so that we don't try to "release" artifacts into this
cache? But temporary storage for the duration of one bui
Hi all,
while the new build machines are fast, some of you pointed out we're
now spending a relative high amount of time downloading maven
dependencies, this problem being compounded by the fact we "nuke" idle
slaves shortly after they become idle.
I just spent the day testing a distributed file
12 matches
Mail list logo
