Removes unused `configFile` input

The configFile input was removed in the @foo-software/lighthouse-check dependency in a previous release and unfortunately we neglected removing this input from the GitHub Action, hence doing that here.

Lighthouse 12

This release upgrades dependency versions, specifically @foo-software/lighthouse-check that upgrades @foo-software/lighthouse-persist that upgrades lighthouse to version 12.0.0.

Lighthouse 10

This release bumps Lighthouse to version 10. See the article from Google about the interesting changes this version provides.

foo-software/lighthouse-check-action depends on other foo-software GitHub projects. Below are the 2 related PRs.

• foo-software/lighthouse-persist#23
• foo-software/lighthouse-check#80

Adds a small delay in between multiple runs

When multiple Lighthouse audits run via multiple URLs defined in the urls option, some faced an issue in which Lighthouse was not launching Chrome as described in #109.

It seems as though when upgrading our Node.js runner to version 16 the linked issue above started occurring. There seems to be 2 issues at play.

1. Chrome Launcher intermittently fails to launch and does not throw an error or surface the problem in any way when Lighthouse runs consecutively in GitHub runners, which causes Lighthouse to mysteriously fail as it is unable to connect. It's unclear why this started happening on Node.js@16. lighthouse-persist is the package used that orchestrates Lighthouse and I attempted to detect chrome.pid and add retry logic, but unfortunately there is another issue with Chrome Launcher in which chrome.pid is undefined.
2. In GitHub's Node 14 runner, when Chrome Launcher failed as described above, the try / catch / retry logic catches the error and succeeds on the first retry as seen here, but in GitHub's Node 16 runner the retry as described above seems to fail and the error bubbles all the way up on the first try and the retry logic isn't triggered as seen here. This is quite unusual, as we use a try / catch block which should catch any errors.

The above are caused by a combination of dependencies that seem to have unclear issues and even unclear sources (GitHub Runners? Chrome Launcher? Lighthouse?). And since these issues are out of our control, the best way I can offer to workaround them, is by adding a 1 second delay in between consecutive Lighthouse audits. My theory is that Chrome Launcher isn't correctly signaling when it is in fact launched and when it has been killed and therefore by giving it some time, we cushion the real problem.

Miscellaneous Dependency Upgrades

v9.1.0

9.1.0

Fast fail when runtime errors occur

Summary

In light of #99 this GitHub Action will now fail a job when Lighthouse results in a runtime error (only applies to "local" Lighthouse runs). This GitHub Action allows for multiple Lighthouse audits within a single job, so if any encounter a runtime error - it will "fast fail" the entire job. maxRetries input will cover these errors and retry if set.

There is an argument to not fast fail the job when these types of errors occur as one may want to preserve runs of other Lighthouse audits within the job, however this would lead to complications in downstream behavior and could cause silent, ignored issues that may eventually become tricky to pinpoint. If a Lighthouse audit is failing with runtime errors, something is wrong that should be addressed, hence another justification of failing the job.

Because this release changes the way errors are handled it is considered a major change in terms of versioning.

Surface Lighthouse runtime errors

Summary

Catches and surfaces runtimeError from Lighthouse result for more verbose output in the logs, comments and Slack messages.

Related

• #96
• foo-software/lighthouse-check#67

Minor logging and PR comment updates

v8.0.1

8.0.1

Improved output to support partial results

Summary

Bumps @foo-software/lighthouse-check to only output results when they exist. For example with 'onlyCategories': ['performance']' we should only output performance scores.

Issues

• #81

Upstream

• foo-software/lighthouse-check#63

Breaking Change Notes

This is considered a "breaking change" only because it changes the output. Previously scores for categories that were not present would be represented with 0 numbers and now they are excluded altogether. It's unlikely you are relying on this.

Updates `node_modules` with Node 16

This change was done just for good measure. No issues were found as it was.