#incremental-build
Posts
-
Digging into Gradle's Source 10: The Execution Engine and Incremental Builds — How UP-TO-DATE Is Decided
How does the single word UP-TO-DATE on your console get decided in the source? We follow DefaultTaskNodeExecutor, which filters tasks before the engine, TaskExecution, which wraps a task as a unit of work, the execution engine built from twenty-five nested steps, ResolveChangesStep and SkipUpToDateStep, which compare the last execution record with the current state, the file fingerprints that @PathSensitive changes, the VFS that remembers file state between builds, and InputChanges, which hands a task only the files that changed — all checked against the source with examples we actually ran.
-
Digging into Gradle's Source 11: The Build Cache and the Configuration Cache — Two Ways to Reuse Work
Where in the source do FROM-CACHE and "Reusing configuration cache." come from? This post covers ResolveMutableCachingStateStep and BuildCacheStep in the execution engine's step chain, what goes into the MD5 cache key, @CacheableTask and the list of reasons not to cache, the local directory cache where the key is the file name and each entry is a tar.gz, the configuration cache that serializes the whole work graph and reloads it even on the very first build, the fingerprint that catches environment variable reads by rewriting bytecode, and the problem report — all checked against the source at a fixed commit and with Docker examples.