search

MovingBlocks / FacadeApplet

A facade to the Terasology engine that wraps it to run as an applet
Apache License 2.0
4 stars 6 forks source link

Reuse existing signed jars for applet build #19

Open Cervator opened 9 years ago

Cervator commented 9 years ago

Currently signing all the jars take nearly half an hour. Maybe there's a way we can reuse at least the lib jars between builds? If not in the build workspace (sort of makes it dirty) maybe we can sign the jars, stick them in our cache in Artifactory, then use them from there when building the applet and exclude already signed jars from the signing process?

The signing process takes very little cpu/memory but eats up an executor in Jenkins for that duration, which may limit our flexibility to minimize droplet time usage

Still not much of a rush item, got a short-term plan to minimize the impact.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/7717649-reuse-existing-signed-jars-for-applet-build?utm_campaign=plugin&utm_content=tracker%2F1159548&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1159548&utm_medium=issues&utm_source=github).
msteiger commented 9 years ago

This should already be done based on the jars in the "signed" folder. But since the Jenkins task wipes out the working directory, these jars are deleted right before they are re-generated.

Removed the "Wipe" task in Jenkins should do the trick already.

Cervator commented 9 years ago

Yep, I figured we could leave the workspace untouched and get that behavior. But in that case would we be cleaning well enough? Say we upgraded a random lib jar from v1.0.3 to v1.0.4, without a full clean would we correctly get the v1.0.3 jar removed, or would it still get packed forever, along with the new one?

A Gradle sync task is smart enough to remove stuff that isn't supposed to be somewhere if inputs/outputs are defined carefully. But I haven't tested that and am skeptical we're in that good shape :-)

I remember past examples (for the applet even) where the deploy dir would slowly gain all kinds of old versions over time. Now it is simply the Jenkins job's artifact section, which is wiped every time.