Configure gradle build scan plugin

[aalmiray]

This small PR configures the build-scan Gradle plugin (https://guides.gradle.org/creating-build-scans/) which yields further insight into the build, allowing the team to make informed decisions on where and when the build may be tweaked to get faster, more performant builds.

[nedtwigg]

Thanks @aalmiray. I'm a fan of the build-scan plugin, but I'm not sure what the use case here is. I've always used it by turning it on to debug an issue, then turning it back off.

What's the recommended workflow for enabling this in CI on a public repo?

[aalmiray]

Initially the scan will give you insight on how the build performed, probably detect any hot spots if they exist. Having faster builds helps reviewing and accepting PRs easier. In the future I hope that we can bring more features to scans such as scores and recommendations.

On CI the recommended way is to run with the build-scan plugin enabled by default. If you want I can update the PR to disable the default acceptance of terms of service, leaving it to the individual developer to accept or reject them.

[nedtwigg]

If you want I can update the PR to disable the default acceptance of terms of service, leaving it to the individual developer to accept or reject them.

That would be great!

In the future I hope that we can bring more features to scans such as scores and recommendations.

Sounds good. I feel a little weird auto-accepting a TOS on behalf of any possible contributors, but if we can make that part optional, I'm happy to merge this and position ourselves to be ready to get these advantages.

BTW, at DiffPlug internally we've recently adopted the gradle build cache, we've been blown away by the workflow improvement. I was very skeptical and we adopted it late, but I've learned to trust Gradle's advice when it comes to builds :)

[nedtwigg]

Apologies, I didn't see that there had been progress on this. I checked out the branch and ran ./gradlew jar, and I got this message:

This build uses Gradle Build Scans to gather statistics, share information about 
failures, environmental issues, dependencies resolved during the build and more.
Build scans will be published after each build, if you accept the terms of 
service, and in particular the privacy policy.

Please read 
   
    https://gradle.com/terms-of-service 
    https://gradle.com/legal/privacy

and then:

  - set the `GRADLE_SCANS_ACCEPT` to `yes`/`no` if you agree with/refuse the TOS
  - or create the /Users/ntwigg/.gradle/build-scans/spotless/gradle-scans-license-agree.txt file with `yes`/`no` in it if you agree with/refuse

And we'll not bother you again. Note that build scans are only made public if 
you share the URL at the end of the build.

Is the intention for every gradle call to trigger this? Or just calls with --scan? As-is, it seems pretty intrusive. Is it possible to limit this to only cases where the user chose to run --scan?

Also, I think the user's call to action could be simpler, maybe just echo "yes or no" > ~/.gradle/build-scans-spotless-license-agree.txt. Something they can copy straight from the message, without having to make a decision of "which way do I accept?".

[aalmiray]

When you run a build with --scan the build will download and configure the build-scan plugin for you if it's not set in the build file. However the query for accepting the terms of service will still appear.

I can rework the commands with your suggestion, I like it.

[nedtwigg]

I can see running a scan on every CI build, but running on every user build by default seems heavy. I do use and like the scans, but I only look at them when I'm explicitly trying to optimize a build which has gotten too slow.

[aalmiray]

Thank you 😄