Gradle 8.8 introduces new features that allow us to avoid using
timestamp manipulation to force the cleanup of the Gradle User Home directory.
This solution is simpler and more robust, but relies on Gradle 8.8+ always being
used for the cache cleanup operation.
Fixes#24
To cleanup Gradle User Home, a Gradle build must be executed.
Newer Gradle versions are able to cleanup the home directories of older versions,
but not vice-versa.
With this change, the latest version of Gradle is automatically provisioned
in order to run Gradle User Home cleanup. This ensures a consistent version of
Gradle is used for cleanup, and fixes#33 where Gradle is not pre-installed on
a custom runner.
- Always fetch a token for every hostname in the access key
- Use any tokens that are successfully fetched
- Retain access key if no tokens can be fetched
Improve readability of build scan when requested tasks is very long, as
agreed in #175. HTML diff for each case of job summary is clearer in
cd62d9c9ef.
- Ensure a minimum size for the badge, at least the size of "Build
scan®", by preventing a line break with ` `
- Reduce the size of the badge by tweaking the inner text
Also fix a typo in the build shell script.
Deprecation warning will be emitted when we:
- Change 'wrapper-validation-action' to delegate to 'actions/wrapper-validation'
- Add the 'wrapper-validation-action' id as env var before delegating
After the '[bot] update dist directory' commit, we run a full test suite.
This will now use the content from the 'dist' directory, rather than
regenerating this content in the test.
This will permit workflows to run when this commit is applied.
- Avoid running ci-update-dist for modifications to dist directory (no recursion)
- Run full-suite only in response to bot updates.
Adds a 'validate-wrappers' option to `gradle/actions/setup-gradle`,
which defaults to 'false'.
When 'true', the action will first validate all Gradle wrappers in the
repository before proceeding.
Fixes#161
Having a single repository to host all of the Gradle GitHub Actions will
provide numerous benefits:
1. Easier to stay on top of dependency updates
2. More frequent release cycle
3. Enable integration between different actions like automatic wrapper
validation with `setup-gradle`.
Instead of relying on push triggers in general, we now use pull_request
and reserve push triggers for main and release branches.
This makes the behaviour more consistent for users contributing from
repository forks. However, we no longer have a quick-feedback loop
for development.
Different runners have different JDKs installed, so using a hard-coded
list for
`toolchains.xml` doesn't work. With this change, the file is generated
based on the available `JAVA_HOME_*` environment variables.
Fixes#89
Thanks @hfhbd for the contribution!
Co-authored-by: hfhbd <22521688+hfhbd@users.noreply.github.com>
Instead of requiring that developers keep the 'dist' directory up-to-date,
this process is now automated via a workflow.
Whenever a commit is pushed to 'main' (or a 'release/**' branch), the workflow will
build the application and commit any changes to the 'dist' directory.
A bunch of improvements to the GHA workflow pipeline including:
- Separate workflow for unit tests
- Always use a locally-built dist directory for integ-tests
- Only run 'quick' integ-tests for non-PR commits. Once a PR is submitted, the 'full' suite will be run on each push.
Without a mechanism to check this in the workflow trigger,
we instead run the workflow but skip all jobs if the commit belongs to a PR.
This effectively means that commits-without-PR will run quick-check, and commits-with-PR
will run full-check.
- Adds an upgrade-guide to assist with resolving deprecations
- Emit a warning when deprecated features are used
- List all deprecated features in Job Summary and link to upgrade guide
On long-lived machines, it's possible that the `.build-results` directory isn't cleared between invocations. This will result in the job summary including results from previous jobs.
By marking each build-results file as 'processed' at the end of the job, we can avoid this scenario.
- Add `RELEASING.md` to document the release process
- Mention the recommendation to disable local build-cache when remote
build-cache is available. Fixes#102
- All cache keys are now structured as `gradle-<cache-name>-<protocol-version>-<key>`. This ensures that extracted entries are prefixed and versioned consistently
- Avoid using custom cache-key prefix for extracted entries. This should reduce the churn in integration tests that require some level of cache isolation.
As a result of this change, cache entries written with previous versions of the action will not be used.
- All cache keys are now structured as 'gradle-<cache-name>-<protocol-version>
- This ensures that extracted entries are prefixed and versioned consistently
- Avoid using custom cache-key prefix for extracted entries. This should reduce the
churn in integration tests that require some level of cache isolation.
