- 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
Follow up of https://github.com/gradle/actions/pull/224, we now attempt to set both old and new access key env variables to a short lived token.
If a short-lived token cannot be obtained, then:
- DEVELOCITY_ACCESS_KEY is set to an empty string, preventing this from being used.
- GRADLE_ENTERPRISE_ACCESS_KEY is left intact, with a deprecation warning being issued.
The setup-gradle action tries to get a short-lived access token given the supplied Develocity access key.
This key can be passed either with the `DEVELOCITY_ACCESS_KEY` env var or via the `develocity-access-key` input parameter.
If a token can be retrieved, then the `DEVELOCITY_ACCESS_KEY` env var will be set to the token.
Otherwise the `DEVELOCITY_ACCESS_KEY` will be set to a blank string, to avoid a leak.
---------
Co-authored-by: daz <daz@gradle.com>
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
cd62d9c9efc15c90df77242059b98bdaa4f39a43.
- 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
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>
- 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.
- 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.
While `setup-gradle` must wait until the end of job to submit all of the generated
graphs, the `dependency-submission` action will not save/upload the generated graph
immediately, in the same step where it is generated.
