Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configure gradle build scan plugin #356

Merged
merged 5 commits into from
Mar 14, 2019
Merged

Configure gradle build scan plugin #356

merged 5 commits into from
Mar 14, 2019

Conversation

aalmiray
Copy link
Contributor

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
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Member

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
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Member

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.

@nedtwigg nedtwigg merged commit 2532984 into diffplug:master Mar 14, 2019
@aalmiray
Copy link
Contributor Author

Thank you 😄

@aalmiray aalmiray deleted the gradle-build-scan branch March 14, 2019 21:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants