Automate Lighthouse Audits with GitHub Actions

Instructor: [0:00] To get started adding Lighthouse to a GitHub Actions workflow, we'll need to create a .github directory at the root of our project, if we don't have one already, and, inside that, a Workflow directory. I already have one here. Inside this directory, we'll create a new YAML file named lighthouse.yml.

[0:18] We'll start out by giving this workflow a name, and we'll specify that it should run automatically after every push or pull request for the main branch. Now, we'll go ahead and define the job. Again, we'll need to give it a name. We'll need to specify what machine this job is going to run on. Now, we'll need to define the steps that it should take.

[0:41] First, we're going to check out the repo, and then we'll install Node version 14. The next step will be to prepare our application to run in order for Lighthouse to audit it. For my application, that includes running npm install and building my app. Now, we're ready to run the Lighthouse CI tool.

[1:04] To do that, we need to install it first, and then we can call the autorun command. Note, I'm not passing any CLI flags to the autorun command because I already have a configuration file in my project, which Lighthouse will automatically detect and use.

[1:23] Speaking of the configuration file, we'll need to make one modification to it in order to run Lighthouse with our continuous integration suite. We'll need to add a property specifying the location where the result reports will be uploaded.

[1:35] Here, I'm specifying that Lighthouse should use the temporary public storage location that it provides for free. Now, I should be all set to push a PR and see what this workflow looks like when it runs. Here, we can see the Lighthouse workflow has automatically started running.

[1:53] Now that the Lighthouse workflow has completed, we can see that it failed, and we can look at the details here. We can see where Lighthouse started running. It found our configuration file. It ran its suite of audits three times. We had some failures, but these are not the most readable.

[2:12] Thankfully, there is a Lighthouse CI GitHub app that can help give us a nice easy-to-read repo inside of our PR. We can get that set up by going to the Lighthouse CI GitHub app and clicking on the Install button and selecting which organization or repo you want to install it into.

[2:32] I'm selecting my personal account. I'm going to install all repositories. You will need to save this token somewhere safe, like a password manager, in case you wish to use this app with other repos as well. Now, I need to go set this token up in my build environment.

[2:51] If I go back to my repo, and I go to Settings and then Secrets, here, I can add a new repository secret. This needs to be named lhci GitHub app token. Then I'll just paste in the token that I was given by the app. Here now, we can see that it's been added to my repository as a secret.

[3:15] Now, I need to go back to my workflow YAML, and I can add this token as an environment variable used by the Lighthouse CI. We'll also want to set the ref of the head of our pull request, which is going to be used by the lighthouse CI GitHub app. Now, once I push these changes, let's go ahead and see what the results look like in my PR.

[3:37] Now that my audit has completed, we can see that there's this new line item here under our checks for the login URL that we specified for Lighthouse to audit, and it shows the accessibility score from the result of the audit.

[3:50] If we go to Details, we can now see this nicely formatted repo. It shows my score. It shows the issues that it found, a list of audits that it ran in the past, and a list of audits that were not applicable to this URL that it audited. Then it details the various runtime settings that this audit was performed in.