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.
Finishes the migration of `dependency-submission` to a Typescript action
(fixes#116)
- Use consistent input params to ensure behaviour is consistent with
'setup-gradle'
- Submit generated graph immediately instead of waiting until end of job
(fixes#123)
- Can now add a `dependency-submission` step after a `setup-gradle` step
in the same job (fixes#36)
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.
The original implementation was a thin `composite` wrapper that delegated to `setup-gradle`.
It is now a full-fledged action sharing implementation details.
