Build cache fixes #3335
Build cache fixes #3335
Conversation
Previously, the graphql-java build would always produce a new version number based on the current date and time in local development. Because the version number would always be different between 2 Gradle invocations, some tasks, such as `javadoc` or `jar` could never be cached because they depend on the version number. With this patch, the version number will no longer include the date and time when the Git workspace is clean, because the commit hash is sufficient to uniquely identify the state of the workspace. This allows the tasks that depend on the version number to be properly cached.
Previously, the cache key of the antlr task would be computed using (among other things) the absolute paths of its input files. Because the absolute paths were part of the cache key, the build cache would rarely be hit. With this patch, the task is configured to use relative paths when computing the cache key.
|
Thanks for this PR - we are all for better builds and faster build times.
can I ask what cache we are talking about here - it's is a gradle external cache or just locally. We have to add more to this PR to cater for the Every merge to master is released as a https://repo1.maven.org/maven2/com/graphql-java/graphql-java/0.0.0-2023-09-12T06-21-36-aae3069/ This is driven by this GitHub workflow : https://github.com/graphql-java/graphql-java/blob/master/.github/workflows/master.yml and it currently drives the build as I think this PR as is will have a clean git state and hence the master release version will be We need to tweak the above code and the workflow such that we indicate we WANT a |
|
Hi @bbakerman, thanks for taking a look.
These fixes would apply to any cache. At the moment, since there's no remote cache configured, it would apply only to the local cache however. With these fixes, the result of the You're right that with this PR, releases on merge would no longer include the date and time in the version number. I'm thinking that maybe a better strategy to generate the version numbers would be:
This way, there'll be no changes in the product of CI builds and local development will benefit from the local cache regardless of the developer workflow (eg. always commit before build). What do you think? |
I like that idea. |
|
Hi @bbakerman , I've updated the build to follow the versioning scheme that we discussed. Please let me know what you think. |
|
Thanks! |
3 participants
Use stable version number on clean workspace
Previously, the graphql-java build would always produce a new version
number based on the current date and time in local development. Because
the version number would always be different between 2 Gradle
invocations, some tasks, such as
javadocorjarcould never becached because they depend on the version number.
With this patch, the version number will no longer include the date and
time when the Git workspace is clean, because the commit hash is
sufficient to uniquely identify the state of the workspace. This allows
the tasks that depend on the version number to be properly cached.
Relativize Antlr sources in cache key
Previously, the cache key of the antlr task would be computed using
(among other things) the absolute paths of its input files. Because the
absolute paths were part of the cache key, the build cache would rarely
be hit.
With this patch, the task is configured to use relative paths
when computing the cache key.