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.
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.
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.
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.
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.
Now, a `dependency-submission` step will trigger a dependency-graph
generation, even if it follows a `setup-gradle` step in the workflow.
Similarly, a `setup-gradle` step with `dependency-graph` configured
will function as expected even if it follows a `setup-gradle` step.
Instead of being a thin wrapper over `setup-gradle`, the `dependency-submission`
action is now a fully-fledged action sharing implementation with `setup-gradle`.
To handle the rebranding of the GE plugin, this PR updates the inject-develocity init script
to apply the `com.gradle.develocity` plugin if `3.17+` version of the plugin is requested.
