https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
c
Is there a reason why publishing is separated into a separate CI task? Generally it needs to know a whole lot of configuration/context, overlapping with how artifacts are built, dependencies, etc.
t
Well, yes, this is a release pipeline, I want to build first, then test, then upload. If the test fails I’d otherwise have to delete the upload, because our prod repo cannot upload identical artifacts again (company policy).
c
the Gradle build cache can possibly help here - publishing would look at all the dependent tasks and have the build cache results satisfied, thereby not needing to run them again.
t
Gradle build cache is in place and doesn’t help. Just did the experiment - I kept all of <mymodule>/build and cleaned the rest of the repo. Then I executed my publish task again, and still, my app was compiled again.
c
build cache is stored in 
~/.gradle/caches/build-cache-1
. Running with `--info`will indicate, for each task, why it wasn’t up-to-date.
👍 1
If you wish to change the location:
Copy code
buildCache {
    local {
        directory = File(rootDir, "build-cache")
        removeUnusedEntriesAfterDays = 30
    }
}
(in settings.gradle.kts)
l
Given your setup, my recommendation would be to take a slightly different approach: • In your build, use 
maven-publish
to push to a local repository • In the following step, publish the content of the local repository to your remote repository. This however would have to be done outside of a Gradle build. That is 
maven-publish
is not designed for this.
t
That's an interesting idea, indeed!
Especially since I really only have to take over the artifacts from one build onto the other that are uploaded, not any other intermediate cruft. This speeds things up as well!
Open in Slack
PreviousNext
Powered by