Examples
The Lighthouse Check GitHub Action provides many features. Each example below illustrates different available features.
Basic#
In the basic example below Lighthouse will run on the 2 URLs via urls input. Results will log to the GitHub Action console. Results will log to the console for all examples.
Save HTML Report Artifacts#
In the example below we do the same as above, but also save HTML reports as GitHub Action artifacts.
Save HTML Reports to AWS S3, Slack Notifications and PR Comments#
In the below example we do the following:
- Run Lighthouse on 2 URLs
- Upload reports to AWS S3.
- Notify via Slack with details about the change from Git data.
- By specifying the
pull_requesttrigger andgitHubAccessToken- we allow automatic comments of audits on the corresponding PR.
Running on Foo and Saving Results#
Foo automates Lighthouse testing by monitoring your website. It can provide a historical record of audits over time to track progression and degradation of website quality. Create a free account to get started. With this, not only will you have automatic audits, but also any that you trigger additionally. Below are steps to trigger audits on URLs that you've created in your account.
Trigger Audits on All Pages in an Account#
- Navigate to your account API page, and make note of the "API Token".
- Use this account API token as the
fooApiTokeninput.
Trigger Audits on Only Certain Pages in an Account#
- Navigate to your account API page, and make note of the "API Token".
- Navigate to any page from your page dashboard and not the "page API token" at the top.
- Use the account token as the
fooApiTokeninput and page token (or group of page tokens) asurlsinput.
Trigger Audits on Only Certain Pages in an Account with Different URLs#
If you want to trigger audits on pages you've added on Foo, but using different URLs. For example, if you use Vercel, Netlify, or CloudFlare to deploy an ephemeral URL in a PR and you want to track it on Foo under one "page" you can do so with the urlsJson input.
For an example on how to do this see the Vercel example.
Pro Tip: In order to do the above, you'll need to have 2 Foo tokens. Firstly, you'll need the API token found in your account. Secondly, you'll need the "page token" found in the page dashboard for the corresponding page.
Overriding Config and Option Defaults#
Note: this approach is not supported when running on Foo.
You can override default config and options by specifying overridesJsonFile option which is consumed by path.resolve(overridesJsonFile). Contents of this overrides JSON file can have two possible fields; options and config. These two fields are eventually used by Lighthouse to populate opts and config arguments respectively as illustrated in "using programmatically". The two objects populating this JSON file are merged shallowly with the default config and options.
Example content of
overridesJsonFile
Vercel#
This example utilizes and assumes a setup of Vercel Action.
Vercel with Foo#
If you're utilizing Foo to save results, you can associate a URL via the urlsJson input similar to the below. Note the use of the tuple, the first value being the Foo page API token and the second being the ephemeral URL.
Pro Tip: In order to do the above, you'll need to have 2 Foo tokens. Firstly, you'll need the API token found in your account. Secondly, you'll need the "page token" found in the page dashboard for the corresponding page.
Failing Workflows by Enforcing Minimum Scores#
In the below we use foo-software/lighthouse-check-status-action@master to verify minimum scores and fail the workflow if they aren't met.
Pro Tip: In order to identify Lighthouse result output, you add an
idso that the output can be consumed from a later step. In the example below, note that we addid: lighthouseCheckfrom theLighthousestep and the consume the output in the later stepVerify Lighthouse Check resultswith${{ steps.lighthouseCheck.outputs.lighthouseCheckResults }}.