Improve cacheability of agent shadowJar task#11878
Conversation
PerfectSlayer
added
the
tag: no release notes
This comment has been minimized.
This comment has been minimized.
🟢 Java Benchmark SLOs — All performance SLOs passed
PR vs. master results
Commit: Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion. |
There was a problem hiding this comment.
Good find the transformer looks like the modern way achieve this.
I had to look why the actions, while serializable (as they do not capture any state), did not allow caching. Turns out that fileMatching calls behind the hood eachFile which toggle a flag hasCustomActions , and this flag is is queried upon asking if this task should cache its outputs.
this.getOutputs().doNotCacheIf(
"Has custom actions",
spec(task -> rootSpec.hasCustomActions())
);
|
By the way, I'd like to note that any call on the |
| transform<ApacheLicenseResourceTransformer>() | ||
| transform<ApacheNoticeResourceTransformer>() | ||
| failOnDuplicateEntries = true |
|
Curious, how do you go about testing this change? Also, similar to my concern in #11856, what happens if |
I'm using @bric3 jardiff tool to check before and after those changes no regression were introduced.
The build will fail, same as a compiler issue, it means your changes introduce a regression. Your changes must have updated the packaging rules and you need to rework it. |
This is a good question. In my head for #11856, the introduced task takes in a reference jar, and I wanted to add later an optional job (because most of the PR actualy touch the code) that could compare the generated jar with the master jar (from the base commit). Meanwhile, it can be done manually with |
|
For the record, which are only changes related to version number and sha1. See the attached file for full diff content: changes.txt |
|
/merge |
|
View all feedbacks in Devflow UI.
The expected merge time in
|
3 participants
What Does This Do
This PR removes the custom actions (
filesMatchingwith closures) that prevent the task to be cached by Gradle.It uses the default shadow jar mechanisms instead:
failOnDuplicateEntriesthat ensure the zip file do not have duplicate entryThis is needed as resource duplication is needed for the transformer to merge them but the
failOnDuplicateEntriesis the safety check that there won’t be duplicate after resource transformation.Motivation
The goal is to help with build cache and avoiding recreating the JARs when publishing them to maven central - so it’s effectively the same artefact that will be tested and published.
Additional Notes
I have additional ideas for the index generation too I need to review first before making a PR with.
Contributor Checklist
type:and (comp:orinst:) labels in addition to any other useful labelsclose,fix, or any linking keywords when referencing an issueUse
solvesinstead, and assign the PR milestone to the issue/merge. You can also:/merge --commit-message "..."/merge -c/merge -f --reason "reason"; please use this judiciously, as some checks do not run at the PR-level (note: the PR still needs to be mergeable, this will only skip the pre-merge build)Jira ticket: [PROJ-IDENT]