Extract init-script contents out of 'develocity-gradle.yml'

[bigdaz]

Previously, init-script content was inlined directly into 'develocity-gradle.yml'

To facilitate sharing and ease maintenance, these contents have been extracted into separate files.

• Raw init-script content in src/gradle/init-scripts
• Template for yml file in `src/gradle/develocity-gradle.template.yml'
• Build script to regenerate final yml is build.sh
• The build-verification workflow verifies that the develocity-gradle.yml file in the repo is up-to-date with respect to source inputs

[alextu]

Nice ! So if understood correctly, the dev flow should look like this:

• make change to an init script locally
• run build.sh locally
• push
• the workflow will run build.sh as well, compare the commited develocity-gradle.yml with the generated one and fail if different (right ?)

[bigdaz]

Nice ! So if understood correctly, the dev flow should look like this:

• make change to an init script locally
• run build.sh locally
• push
• the workflow will run build.sh as well, compare the commited develocity-gradle.yml with the generated one and fail if different (right ?)

Yes, this is what I've implemented. It requires a manual process to update develocity-gradle.yml, with a workflow that will ensure this has been done. Since we don't expect frequent updates to the reference init-script, this seemed suitable.

Another option is to have a workflow that runs build.sh and auto-commits any change. We do this now in gradle/actions to generate the output, but it has some drawbacks:

• Tests would need to be updated so that we run build.sh locally before testing: otherwise for any PRs you could be testing the old develocity-gradle.yml file.
• It's not possible to trigger another workflow from an auto-generated commit

[alextu]

Nice ! So if understood correctly, the dev flow should look like this:

• make change to an init script locally
• run build.sh locally
• push
• the workflow will run build.sh as well, compare the commited develocity-gradle.yml with the generated one and fail if different (right ?)

Yes, this is what I've implemented. It requires a manual process to update develocity-gradle.yml, with a workflow that will ensure this has been done. Since we don't expect frequent updates to the reference init-script, this seemed suitable.

Another option is to have a workflow that runs build.sh and auto-commits any change. We do this now in gradle/actions to generate the output, but it has some drawbacks:

• Tests would need to be updated so that we run build.sh locally before testing: otherwise for any PRs you could be testing the old develocity-gradle.yml file.
• It's not possible to trigger another workflow from an auto-generated commit

I think the current "manual" approach is best