Skip to content
This repository was archived by the owner on Feb 21, 2025. It is now read-only.

Improve caching of downloaded Gradle distributions #55

Closed
wants to merge 16 commits into from

Conversation

bigdaz
Copy link
Member

@bigdaz bigdaz commented Jul 6, 2021

  • Improves test coverage of Gradle invocations, separating unit test data from sample Gradle builds
  • Removes the wrapper-directory option: use the gradle-executable flag for this (uncommon) purpose
  • Renames the rc option to release-candidate for consistency with other resources
  • Only cache the downloaded zip file for a wrapper invocation: Gradle will automatically expand this if required
  • Cache distributions that are downloaded for a specified Gradle version

bigdaz added 16 commits July 5, 2021 12:05

Unverified

This user has not yet uploaded their public signing key.
Updates transitive library versions to address known vulnerabilities

Unverified

This user has not yet uploaded their public signing key.
Get latest versions of transitive deps.

Unverified

This user has not yet uploaded their public signing key.

Unverified

This user has not yet uploaded their public signing key.

Unverified

This user has not yet uploaded their public signing key.

Unverified

This user has not yet uploaded their public signing key.
- Use built-in `hashFiles` function included in '@actions/globv0.2.0'
- Use `downloadTool` and `extractZip` functions from '@actions/tool-cache'

Unverified

This user has not yet uploaded their public signing key.
- Remove the 'gradle --stop' step from the prod workflow.
  We either need to stop all instances started, or rely on GitHub to clean up processes on completion.
- Remove configuration-cache and dependencies-cache from basic tests. We will later need to add
  tests invocations specific for these features.

Unverified

This user has not yet uploaded their public signing key.
This removes the need to specify `wrapper-directory` when using a Gradle
project that is not located in the root of the workspace.

Fixes #44.

Unverified

This user has not yet uploaded their public signing key.
- Upgraded `samples/basic` to use latest Gradle version.

Unverified

This user has not yet uploaded their public signing key.
Will use this for testing Gradle execution with different versions and mechanisms.

Unverified

This user has not yet uploaded their public signing key.
Use matrix to allow different script suffix on windows

Unverified

This user has not yet uploaded their public signing key.
- Provide a more useful error message when no Gradle wrapper can be located,
  and 'gradle-version' or 'gradle-executable' is not used.
- Add test for case where wrapper is missing.
  This isn't really a "test" per-se, but this failing build invocation makes it
  easy to verify the GitHub action behaviour when the build is misconfigured.

Unverified

This user has not yet uploaded their public signing key.
In the (rare) case where using a non-default Gradle wrapper is required,
the `gradle-executable` paramater can be used.

Unverified

This user has not yet uploaded their public signing key.
This makes the version alias match other places where we reference a
release candidate version.

Unverified

This user has not yet uploaded their public signing key.
Prior to this change, the wrapper cache contained both the downloaded zip
file as well as the exploded wrapper dir. Only the zip file is required,
as Gradle will automatically detect and unpack.

Unverified

This user has not yet uploaded their public signing key.
- Cache is separate from (but similar to) the wrapper distribution cache
- Renamed the 'wrapper-cache-enabled' flag to 'distributions-cache-enabled': this flag
  now controls both wrapper and regular distribution caching
@bigdaz bigdaz requested a review from eskatos July 6, 2021 00:31
@eskatos
Copy link
Member

eskatos commented Jul 6, 2021

I'm +1 on the changes!

This PR breaks backwards compatibility of the workflows by removing/renaming inputs though.

We have two options for this:

I'd be happy either way but backwards compatibility sounds good to me because we can ship improvements to people without requiring them to change their workflows.

What do you think?

@bigdaz
Copy link
Member Author

bigdaz commented Jul 6, 2021

Thanks @eskatos . I'm going to close this in order to separate the useful v1 changes from breaking v2 changes.

@bigdaz bigdaz closed this Jul 6, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants