Logging of the AZURE_LOG_LEVEL env var value is considered a security issue,
since any environment variable value could contain sensitive information.
In this case, logging the value is not really necessary.
The included sourcemap-register.js file is triggering a high priority
CodeQL warning, which can prevent users from adopting the action.
Removing this sourcemap support for now, until this can be fixed upstream.
- Bump @actions/cache from 2.0.4 to 2.0.5
- Bump ts-jest from 28.0.2 to 28.0.3
- Bump typescript from 4.6.4 to 4.7.2
- Bump @vercel/ncc from 0.33.4 to 0.34.0
Production deps:
- Bump @actions/tool-cache from 1.7.2 to 2.0.1
- Bump @actions/http-client from 1.0.11 to 2.0.1
- Bump @actions/github from 5.0.1 to 5.0.3
- Bump @actions/cache from 2.0.2 to 2.0.4
Dev deps:
- Bump eslint from 8.14.0 to 8.15.0
- Bump eslint-plugin-jest from 26.2.0 to 26.2.2
- Bump jest from 27.5.1 to 28.1.0
- Bump ts-jst from 27.1.4 to 28.0.2
Production deps:
- Bump @actions/core:1.6.0 to 1.8.2
Development deps:
- Bump typescript from 4.6.3 to 4.6.4
- Bump @typescript-eslint/parser from 5.20.0 to 5.23.0
- Bump eslint-plugin-jest from 26.1.4 to 26.2.0
- Switch from deprecated @zeit/ncc to @vercel/ncc
To save space, future versions of Gradle are likely to delete the downloaded distribution
after extracting it. See gradle/gradle#3605 and gradle/gradle#19495.
To cater for this we will now save/restore the extracted distribution rather than the
downloaded zip file.
This is a pure refactor, moving from a separate .cache file per bundle to a single cache-metadata.json file describing all bundles. Instead of storing cache metadata in a separate .cache file per artifact bundle, all of the metadata is now stored in a single `.json` file.
This will make it easier to implement more flexible artifact-caching strategies, such as caching each wrapper zip separately.
* Always include cache protocol version in cache key
* Store all cache metadata in a single JSON file
* Rename cache-metadata file and bump protocol version
* Polish and documentation
Failures to store cache entries should not fail the action or the Job.
This fix attempts to catch and log any unexpected errors that occur when
saving cache entries.
Fixes: #119Fixes: #120
- Warn and continue on failure to restore a Gradle distribution from cache
- Warn and continue on failure to save a Gradle distribution to cache
- Extract common functionality for consistent handling of cache failures
Fixes#116
Instead of parsing the log output, we instead register a
buildScanPublished listener and record the build scan URL
to a file. This file is subsequently read to report the
build scan URL.
Fixes#30
When caching is too fine-grained, an excessive number of cache
requests can result in HTTP 429 errors due to rate limiting.
By caching all artifacts of a particular type in a single entry
we hope to mitigate this, at the expense of some reduction in
cache space optimization.
This change also adds caching for all dependency jars, as well as
instrumented jars in the 'caches/jars-X' directory.
Similar to wrapper distributions, these large files are common
to many Gradle User Home cache entries. Storing them separately removes
this redundancy from the Gradle User Home cache.
In the current model, each cached Gradle User Home could contain
a copy of one or more downloaded wrapper distributions. This results
in large cache entries which could easily lead to premature eviction.
With this change, wrapper dists are cached separately from the rest
of the Gradle User Home directory. The artifact file is replaced by
a marker file which allows the action to restore the artifact from
cache when the Gradle user Home cache is restored.
Cache keys have a hard limit of 512 characters, so we need to ensure that we don't generate a key longer than this.
- Remove excess whitespace
- Truncate to 400 characters
Fixes#70
