Expected Behavior
Currently you can have cacheable transforms that can also make it into and out of the remote build cache.
And you can have the complete outputs of a task cacheable - also remote.
But regularly I would like to be able to cache more fine-grained.
For example on single WorkActions.
Two examples:
A task that compiles all JRXML files to JASPER files but does so via Worker API to parallelize the work.
Now if that task compiles 30 JRXML files and 2 of them changed with the outputs also being different, incremental input processing cannot work and all 30 JRXML files need to be recompiled completely. Would be nice if 28 of them could come from local or remote build cache.
Other example is a task that signs files using a remote sign server, for example a SignServer instance with a Nitrokey HSM 2 attached to it. Such signings are rather slow, especially when many build agents or also developers send signing requests at the same time. With this a task of signing 75 files that would need 5 minutes if you are the only one requesting singing can easily need 3 - 4 hours (numbers are not made up but happened like that here). The 5 minutes alone are already a sad wait time. If nothing changed in the complete inputs of the task, the whole output can of course come from the build cache. But it would be nice to be able to send these signing requests for example to the worker api which then can individually get the signed files from the build cache instead of doing the signing again.
Expected Behavior
Currently you can have cacheable transforms that can also make it into and out of the remote build cache.
And you can have the complete outputs of a task cacheable - also remote.
But regularly I would like to be able to cache more fine-grained.
For example on single
WorkActions.Two examples:
A task that compiles all JRXML files to JASPER files but does so via Worker API to parallelize the work.
Now if that task compiles 30 JRXML files and 2 of them changed with the outputs also being different, incremental input processing cannot work and all 30 JRXML files need to be recompiled completely. Would be nice if 28 of them could come from local or remote build cache.
Other example is a task that signs files using a remote sign server, for example a SignServer instance with a Nitrokey HSM 2 attached to it. Such signings are rather slow, especially when many build agents or also developers send signing requests at the same time. With this a task of signing 75 files that would need 5 minutes if you are the only one requesting singing can easily need 3 - 4 hours (numbers are not made up but happened like that here). The 5 minutes alone are already a sad wait time. If nothing changed in the complete inputs of the task, the whole output can of course come from the build cache. But it would be nice to be able to send these signing requests for example to the worker api which then can individually get the signed files from the build cache instead of doing the signing again.