logistics: use new pre-cached builder image in Jenkins

[Cervator]

Contains

Changes the label for the engine build to a new one, defined presently using https://github.com/Cervator/pre-cached-jenkins-agent (that repo will likely move and might itself get a build in our Jenkins but - one step at a time) - see its repo readme for more technical details.

In short the goal is to use a Docker build of a custom Jenkins agent to pre-cache our main dependencies (at the moment for the TS engine, joml-ext, and modules), as well as pre-download the files needed for each Gradle wrapper version.

This PR also removes the already-default setting for the Gradle Daemon in case any attempts to experiment are desired elsewhere (has no effect normally). Loooong time since that actually mattered, the setting was changed to true by default years ago.

Label reasoning goes with a potential later change to make light/medium/heavy agents (again), easily vary the version of Java (plus make it more explicit/visible), easily vary / diversify agents later for different archetypes (Terasology engine build vs Destination Sol engine build including Android, for instance)

How to test

Logistics change - tested in Jenkins already. No particular way to test this separately, can just look at the job execution on the Nanoware forks

Performance stats are hard to narrow down since builds may differ in duration based on what else is going on in the cluster. I tried to closely watch a few of them to make sure the system was otherwise idle to guesstimate "best case" improvements

• Nanoware/Terasology:develop build & Nanoware/Terasology:customAgent build vs Existing MovingBlocks/Terasology:develop build - Build (compile) step is faster, from 1-3 minutes (up to 50%), but analytics still take way longer so overall impact isn't huge.
• Nanoware/joml-ext build vs MovingBlocks/joml-ext build - 20s improvement, about 33% faster overall than before
• Nanoware/Sample build vs Terasology/Sample build - nearly 66% reduction in average compile time leads to an overall 50% faster build - just from pre-caching dependencies, including the engine jar in this case 🚀

Outstanding before merging

• This PR goes along with one in the module Jenkinsfile repo - feat: switch label to new Jenkins agent, minor tidying ModuleJteConfig#8
• Doubt: What happens if a module build starts with a snapshot jar of the engine in its Gradle cache, but a newer snapshot is available in Artifactory? We could skip the optimization for module builds until more experimentation can occur.
• Haven't applied it to joml-ext as that was just a handy test candidate for a tiny lib build. More to come on how to apply this more broadly, but have some more ideas to explore first - could push it over there too tho

[keturn]

Well, this PR has two lines in it. +1 on templates/gradle.properties. For the node of the Jenkinsfile: sure why not what's the worst that could happen?

The one thing I'm confused about is that I've looked at this and the pre-cached-jenkins-agent repo and the ModuleJteConfig PR, and I don't see what ties them together. What defines ts-engine and ts-module? Where is the part that points to the pre-cached-jenkins-agent?

Doubt: What happens if a module build starts with a snapshot jar of the engine in its Gradle cache, but a newer snapshot is available in Artifactory? We could skip the optimization for module builds until more experimentation can occur.

Hmm. Does an engine jar end up in the docker image's gradle cache?

Either way, I think this should be fine, but I'm not solid on that. I don't know how snapshot builds are actually compared.

Notes on https://github.com/Cervator/pre-cached-jenkins-agent/

Is this && blah blah \ style the idiomatic way to write Dockerfiles now? Oof.

If this is to prime ~/.gradle but it's not keeping any git stuff, you can probably make those git clones be shallow.

And there's probably a way to make gradle fetch dependencies without actually spending the time to do the compilation. But that can be a later potential optimization. Time to build the docker image may not be the thing we need to optimize for.

[Cervator]

Where is the part that points to the pre-cached-jenkins-agent?

Magic is in the Jenkins k8s cloud definition label field for the pod template:

I didn't doc that in the custom agent repo since it is specific to our label setup in Jenkins. I figure I'll put a comment on that in the InfraPlayground repo when overhauling how we define our agents there.

Is this && blah blah \ style the idiomatic way to write Dockerfiles now?

Ayup, maybe? It seemed to be in use in the Googly bits I drew inspiration from.

git clones be shallow
And there's probably a way to make gradle fetch dependencies without actually spending the time to do the compilation

Yep indeed on both 👍 This is the first working version and I'm fishing for improvements, good call on the shallow clone (Cervator/pre-cached-jenkins-agent@b5c4e76) and I've got a Gradle snippet that fetches deps - actually in Kotlin even! Which means I'm having trouble getting the engine to accept it 😅

Does an engine jar end up in the docker image's gradle cache

Pretty sure yes, since in the past that's where execution ended up starting for some automated tests written in modules. And the engine is a dependency for modules, so the build has to reference it somewhere