Gradle builds can become slower over time as more complexity is added to the build process. By storing the analytics for each build it in the cloud, it is possible to analyze the build history over time and identify issues quickly before they become a problem in production. The Gradle team provides a Cloud analytics platform which allows you to easily post your build statistics and to share statistics from all the developers on your project.
- [Instructor] In this video, we're going to talk about using the Gradle cloud build scan. I'll start out by talking about what the cloud build scan is then we'll see how to send the build output from the build scan to the cloud. Accessing our reports in the cloud will require authentication so we're the only ones who can see our reports. Finally, we'll do a quick review of the build scan reports themselves to see what kind of information they provide. So what is the cloud build scan? Well, first, it's a new capability that's only recently been added by Gradle so it's something that's brand new and something that's likely to change in the near future.
Essentially, it's just a set of build reports. So, similar to what we've already seen in prior videos in profiling, for instance. Except with quite a bit more information. Additionally, these reports are saved to the cloud so they're not on our local machine. The advantage of that is that if you clean out your build directory or move from machine to machine, you can still have access to the cloud instance of the saved reports. And that cloud service is managed by Gradle.
They host the build scan reports. Finally, an advanced feature of the cloud build scan is available as a commercial product from Gradle but we're gonna be focusing on seeing what the free capabilities are. Let's look at some code. I'm back in IntelliJ and I'm using the java project that I've been working on in prior videos. If you're starting from this point, you can load the starter project from the exercise files. Accessing the Gradle cloud build scan does require that we add some additional descriptions in our build.gradle file.
So, let's open that up. I'll scroll to the top and what I need to do is add the plugin for the build scan. So, just before line one, I'll open up a few lines there, and I'll enter the plugin description. So, I'll define the plugin section and then I will provide the ID of the plugin which is com.gradle.build-scan and then I'll supply the version number of the plugin which is 1.6.
Now this looks a little bit different than the way we've been accessing plugins so far but, remember, this is a new feature and the way that we use it will evolve over time. After line three, here on line five, I have a new section for the buildScan itself. One of the things I have to do, because I'm accessing a cloud service, is I have to accept a license agreement. So, in this section, we'll provide some information about where that license agreement is.
So, I'll enter a property called licenseAgreementUrl and I'll specify the location of that license agreement on the internet, which is https://gradle.com /terms-of-service. Then I also have to automatically accept that license agreement so on line seven, I'll enter a property, licenseAgree and I'll specify that I do agree with the license.
Because this is an evolving feature, I have to do one little extra piece of work before I can continue on. And this is something that is likely to change as the plugin becomes more mature. I have to make sure that if I've got any other build declarations that I've put them at the top of the build.gradle file. So I have one in line 28, so I'm going to cut out line 28 through 32 and move that to the top of the build.gradle file before line one.
Okay, now, at this point, I'm ready to run my build scan. So, I'll open up the terminal and I will run a Gradle build, as we've been doing in the past but now I'll add an argument at the end, --scan. And you can see that the build's successful and if I open up the terminal view, I can see that I've got a regular build and all the reporting that comes with that. But I've got an additional message down at the bottom of the terminal view. You can see that I've got a link to a website.
This is the Gradle cloud. So, what I need to do is highlight that, copy it and paste that into a browser. And you'll notice that it now wants to authenticate our usage so, in other words, not anybody can get to this site. I need to tell it who I am. So, I'll enter my email address. I'll click on the remember me check box and this way I won't have to authenticate for each of the build reports and then I'll click go.
At this point, the Gradle cloud will send an email to my inbox with a link that I can use to click on and now become authenticated. Now when I go to that link again, rather than see the authentication screen, I actually see the build report. And, so, let's walk through these sections and see the kind of information that's here. In the summary view, I can see when my build was started, what version of Gradle I was using, what version of the build scan plugin.
I can also use the link to explore console output and, in this case, I'm seeing the same kind of output that I've been seeing in the terminal all along. So, nothing new here but now it gets more exciting. I have, on the left-hand side, I have navigation links to various additional information that I'm not able to see in this same way when doing simple profiling. So, I've got a timeline which will show me the tasks that are running and, visually, how long they took and whether or not they were able to run in parallel. So you can see that my tasks here are sequential.
The next link is for performance and I can see how long the build took and then I have a link that I can use to explore performance in more detail so I can drill down into the various phases of the build and see how long they took. And also, one of the really neat features of this report, is along the menu bar at the top, I can select settings and suggestions. And here, I can see some very useful information. The first bullet point tells me that the build was run with the latest Gradle version, 3.5.
The second bullet point tells me that the build was run with the Gradle daemon which is enabled by default but if, for some reason, you hadn't enabled that, your build would run more slowly. The third bullet point tells me that parallel execution was not enabled and notice that the note under the bullet point says that parallel execution can drastically reduce build time. Additionally, it provides a link where we can learn more about how to enable parallel execution, and I'll leave that for you to explore.
The next link provides us information about the projects so that we can see that we've got three different projects. We can then also see information about the dependencies. Furthermore, we can see a list of all the plugins that we're using and that we've enabled. In the switches section, we can see various Gradle properties that have been turned on or off. So, for instance, in the first line, we can see that we have turned the daemon on. And then, finally, we have an infrastructure section and there, we can see information about the machine that the build was run on.
So, for instance, what operating system the machine was running, how many cores it had, what java runtime we were using, how much memory it used, and this is maintained historically, so when we run on different machines or we change the configuration, that would help us understand why the build might be running faster or more slowly. Finally, I just wanted to remind you that the build scan is an emerging feature so you may want to keep an eye on updates to how to enable the build scan and use it, and here's the website that you can use to do that.
That will take you to a Gradle page that will give you the most recent information on how to use and enable the build scan.
- The purpose of Gradle
- Building a Java project with Gradle
- Adding a dependency to a project
- Creating a library module
- The Gradle project structure
- Creating new Gradle tasks
- Profiling and using the Gradle cloud