Automate Lighthouse Audits with GitHub Actions

Erin Doyle
InstructorErin Doyle
Share this video with your friends

Social Share Links

Send Tweet
Published 3 years ago
Updated 2 years ago

To automate running Lighthouse audits on our application we can add the use of the Lighthouse CI tool to our Continuous Integration suite using GitHub Actions. By making use of the Lighthouse CI GitHub App we can add to the checks in every Pull Request a report with the score from the audit run on each URL we configure for Lighthouse to audit.



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.

~ 33 minutes ago

Member comments are a way for members to communicate, interact, and ask questions about a lesson.

The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on

Be on-Topic

Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at

Avoid meta-discussion

  • This was great!
  • This was horrible!
  • I didn't like this because it didn't match my skill level.
  • +1 It will likely be deleted as spam.

Code Problems?

Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context

Details and Context

Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!

Markdown supported.
Become a member to join the discussionEnroll Today