Vijay Arun09/06/2022, 8:02 AM
Vijay Arun09/06/2022, 8:04 AM
Vijay Arun09/06/2022, 8:09 AM
thadhouse10/27/2022, 3:59 AM
Slackbot11/02/2022, 4:54 PM
Alex Fox12/20/2022, 9:33 PM
in a new class with nothing else in it in our environment, it takes 3.5 minutes to run from clean, and 1.5 minutes to run once built (or if I make a tiny change like changing the test to
. The first thing I’m going for is the configuration step which takes almost a full minute on project
. No additional context. Does that mean the root project or something? It doesn’t break out into categories in the results of
and we don’t seem to have any projects explicitly named
as far as I’ve been able to tell
Gabriel Feo02/08/2023, 4:44 PM
Daan02/09/2023, 9:23 AM
) with just barely enough
memory and see during which task the daemon is running out of memory. We observed that this happens during large copy tasks.
Is this expected to consume significant memory? Did anyone else also observe this? Any information is more than appreciated!
Sherif Nada02/25/2023, 8:35 PM
) in a large monorepo (~50 devs)?
I work in a monorepo with 50+ other engineers touching ~50-60 submodules. Developers will often add new modules or modify build logic for existing modules. It’s very easy for someone who is not familiar with Gradle to break the build’s incrementality.
It’s not practical to expect everyone to be a gradle expert. At the same time, I want the build speed to be optimal. This seems like a great use-case for a CI or build check.
My ideal solution would be for the Gradle build to fail if it finds that any task is not incremental (maybe with the ability to add an escape hatch for tasks which truly can’t be incremental).
Does anyone have experience with implementing something like this? Any pointers would be super appreciated.
Marek03/08/2023, 3:45 PM
ebtokyo03/10/2023, 9:01 PM
Romain Petit03/11/2023, 7:31 AM
Hemanth Sai Veluvolu03/14/2023, 11:29 AM
is ~8000. But according to configuration avoidance documentation, this number should ideally be same. Is there a way to debug why and which tasks are getting unnecessarily created?
Marcin Laskowski03/20/2023, 1:05 PM
Andrew Grosner04/05/2023, 1:43 PM
inter-module dependencies and make most
(including dependencies that are leaked via public API or through code generation like dagger). is there any advantage in performance to making most inter-module dependencies
Zac Sweers04/22/2023, 12:55 AM
ebtokyo04/24/2023, 11:20 PM
but since we moved to Gradle 8.0.2 this measuring is broken, the cache is never stored because
. So we can’t really detect configuration cache regressions.
Is there a better way to measure configuration time in a standalone gradle profiler scenario? OR to address this
Configuration cache entry discarded because incompatible task was found: ':init'.
Doni05/19/2023, 6:08 AM
Satyarth Sampath06/14/2023, 5:05 PM
Brian Stewart06/22/2023, 5:08 PM
subprojects (which seems to result in only 3-5 workers, but we lose parallel subproject compilation)
• Limiting max workers to a much smaller number than CPU cores (which seems to result in fewer workers but still 8-10)
• Splitting the build into two builds: assemble everything in one, run tests after that
Thoughts? Are there any better options?
Nuh Koca06/23/2023, 4:08 PM
Ben Berman06/27/2023, 8:26 PM
, etc. invoke the service provider object instead of the
• allow pieces of configuration to be externalized. for example, we read in configuration files in our
and similar, and we'd like to make the cache aware of that.
twisterrob07/13/2023, 10:53 AM
constraints as far as I see
• parallel builds are on
• read through the plugin code and build.gradle of the project and don't see anything touching Test tasks in this way
• what else can I look at?
• they're using javaToolchains to run on different Java versions, could that cause this?
Here's a scan: https://scans.gradle.com/s/kgpvb2h4jwfbi/timeline?details=k46fkpvj62cf6&show=details
Marcin Erdmann09/06/2023, 3:46 PM
Guilherme Lima Pereira01/12/2024, 2:50 PM
The Daemon enables in-memory caching across builds. This includes classes for plugins and build scripts.
Similarly, the Daemon maintains in-memory caches of build data, such as the hashes of task inputs and outputs for incremental builds.https://docs.gradle.org/current/userguide/gradle_daemon.html#memory_caching
Andrew Grosner01/17/2024, 7:21 PM
Alexander Gherschon02/05/2024, 12:39 PM
But I still see inconsistent results, like as if the cache still plays a role and speeds up the build sometimes
What am I missing?
./gradlew :app:assembleDebug --no-build-cache --no-configuration-cache --scan
CristianGM02/07/2024, 9:32 AM
JamesX02/09/2024, 9:13 PM
will later cause it to be marked uptodate, so it seems more like I'm either not preserving some important
file somewhere, or things are getting invalidated because I'm running in a different container from when the code was previously built and cache files were written for the next build.
We have hotfix branches mostly on 7.4.2, but some as old as 6.2.2. If there's recommended versions where uptodate-checking magically got better, I'd consider attempting an upgrade, but I'm hoping I can figure out why my first run of a cacheable task nets me:
> 2024-02-09T204707.838+0000 [DEBUG] [org.gradle.internal.vfs.impl.AbstractVirtualFileSystem] Invalidating VFS paths: [/home/jenkins/agent/workspace/build/classes/java/main]
followed by messages about deleting my existing files and unpacking them again from build cache.
Once it's completed once, things run uptodate w/o trouble. Any and all advice is appreciated.
Also, it seems only
tasks seem to be affected. I understand compileJava re-running will trigger javadoc, but can't seem to find why
won't stay UP-TO-DATE on first build with an imported cache layer.
files cause uptodate to miss?
Arlind Hajredinaj02/19/2024, 10:27 AM