-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Global caching of signed artifacts #23
Comments
+1 Really desired feature. |
I am working on this feature at the moment. But parallel signing is possible already. Just enable parallel builds using the gradle parameter "--parallel". Or by defining the property org.gradle parallel=true in either your home-gradle.properties or in the project local gradle properties. |
I'm happy to hear that. I can't wait for this feature! Off-topic about paralleling: |
You are right, the This is, however, not what the jnlp-plugin uses. The signJars-task uses gpars to sign multiple jars in parallel (https://github.com/tschulte/gradle-jnlp-plugin/blob/0.2.1/gradle-jnlp-plugin/src/main/groovy/de/gliderpilot/gradle/jnlp/SignJarsTask.groovy#L41). |
Thank you for the clarification. ---- After investigation ----
So, I tried to use non blocking alternative: GParsPool.withPool(8) {
...
AntBuilder ant = project.createAntBuilder()
ant.signjar(jar: jarToSign, alias: keystoreAlias, storepass: keystoreStorepass, keypass: keystoreKeypass, keystore: keystore, tsaurl: 'http://tsa.starfieldtech.com') {
sysproperty(key: 'java.security.egd', value:'file:/dev/./urandom')
}
} But, as you can see I needed to add sysproperty nested parameter to ant signjar task. This solution will speed up jar siging significantly on our jenkins server. |
We are using haveged (http://www.irisa.fr/caps/projects/hipsor/) on our CI-Server to ensure /dev/random is always filled with entropy. Since then our builds never stalled. |
Thank you for advice. |
Is there any progress on this issue? |
BREAKING CHANGE: - removed CopyJarsTask: SignJarsTask does not sign, if no signJarParams are given
I must confess I have not worked on this particular issue in some time. On a branch I did try to break up the sign jars task into one task per jar instead of one big task doing all the signing. The reasoning behind this was to allow gradle to do all the heavy lifting -- both parallelization (using the new incubating intra-project parallelization support) and caching (for this I was hoping for https://discuss.gradle.org/t/distributed-cache/101 to be implemented). But I don't know if this route is the way to go. Dynamically creating tasks depending on the amount of dependency might be a bad idea, because the tasks are created at configuration time, and the dependencies should not be resolved at that time, but without resolution it is not possible to create a task per dependency. Thinks are pretty busy at the moment for me, so I cannot guarantee I will have much time for this, but at least I pushed this ticket up on my TODO list. |
Before, it was necessary to call `clean` after any change to the jnlp extension. refs #23
BREAKING CHANGE: - removed CopyJarsTask: SignJarsTask does not sign, if no signJarParams are given
Before, it was necessary to call `clean` after any change to the jnlp extension. refs #23
This probably comes too late for most people, but I've hacked something together:
The idea is to create one task for each file to be signed. This way the Gradle cache can be used to cache the signed jar files. We are using the official build cache node for remote caching. Because the JNLP-plugin declares an output-folder (not a file), every signed file must be written to its own folder for the caching to work. You have to keep this in mind when building your distribution. As an example you can see my RPM-task above that shows how to flatten the The downside of this approach is that this completely breaks any kind of parallelism. The JNLP-plugin usually uses all workers to sign multiple jar files in parallel, but this doesn't work anymore if the plugin is called for each file separately. Unfortunately, Gradle cannot execute multiple tasks of the same project in parallel, even if they are independent from another. This makes my hack above almost useless, because the build now takes forever if there are uncached artifacts. Bummer. |
If an application has many dependencies, that do not change often, a huge amount of time on each clean build is wasted signing the same artifacts again and again with the same parameters.
There should be an option to cache already signed artifacts. This may be using a maven/ivy repository. This is somewhat related to #22, in that the cached artifact has the same constraints.
The text was updated successfully, but these errors were encountered: