如何在GitHub中使用Lighthouse

GitHub Actions are used to automate software engineering workflows. Similar to tools like CircleCI, Jenkins, Travis and many others, GitHub Actions provides a declarative API for defining workflows. These workflows can include jobs to build, test, and deploy applications.

GitHub Actions用于自动化软件工程工作流。 类似于CircleCI，Jenkins，Travis等工具，GitHub Actions提供了用于定义工作流的声明性API。 这些工作流程可以包括用于构建，测试和部署应用程序的作业。

Lighthouse is an open-source project from Google for improving the quality of web pages. It provides user-centric metrics to audit SEO, performance, accessibility, best practices, and progressive web apps. For a deeper dive about Lighthouse please read “How to analyze website performance with Lighthouse”. This post will demonstrate the following:

Lighthouse是Google的一项开源项目，旨在提高网页质量。 它提供了以用户为中心的指标，以审核SEO，性能，可访问性，最佳实践和渐进式Web应用程序。 要进一步了解Lighthouse，请阅读“ 如何使用Lighthouse分析网站性能 ”。 这篇文章将演示以下内容：

• Basic implementation of Lighthouse in a GitHub Actions workflow.
  GitHub Actions工作流程中Lighthouse的基本实现。
• Advanced setup to display Lighthouse results in pull request comments.
  显示灯塔的高级设置会在请求请求注释中显示结果。
• S3 Lighthouse report uploads.
  S3 Lighthouse报告上传。
• Slack notifications.
  通知松弛。

Lighthouse检查GitHub操作 (Lighthouse Check GitHub Action)

This post will provide a guide for using Lighthouse Check Action for automating Lighthouse audits. It can be used within a workflow - triggered by any event. This post will demonstrate how to use the action when triggered by a pull request event.

这篇文章将提供有关使用Lighthouse Check Action自动进行Lighthouse审核的指南。 它可以在任何事件触发的工作流中使用。 这篇博文将演示在请求请求事件触发时如何使用操作。

基本范例 (Basic Example)

With the following steps we can create a basic workflow.

通过以下步骤，我们可以创建基本的工作流程。

1. Create and checkout a new branch locally.
   在本地创建并签出新分支。

2. Create a file in your project with a path similar to the following .github/workflows/my-workflow.yml (replacing my-workflow with any name of your choice).

   在项目中创建一个文件，其路径类似于以下.github/workflows/my-workflow.yml (将my-workflow替换为您选择的任何名称)。

3. Populate the file from above with the example shown below, replacing the urls field with a comma separated list of the URLs you’d like to test.

   使用下面显示的示例从上方填充文件，将urls字段替换为您要测试的URL的逗号分隔列表。

4. Commit changes locally and push the branch up to your remote.
   在本地提交更改，并将分支推送到远程。
5. From your new branch, open a pull request.
   在新分支中，打开拉取请求。

name: Lighthouse Check
on: [pull_request]

jobs:
  lighthouse-check:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@master
    - run: mkdir /tmp/artifacts
    - name: Run Lighthouse
      uses: foo-software/lighthouse-check-action@master
      with:
        outputDirectory: /tmp/artifacts
        urls: 'https://www.foo.software,https://www.foo.software/contact'
    - name: Upload artifacts
      uses: actions/upload-artifact@master
      with:
        name: Lighthouse reports
        path: /tmp/artifacts

And Voilà 🔮 — we have a workflow with Lighthouse! Assuming you have GitHub Actions enabled in your repo, you should see something like the below (note: at the time of this writing GitHub Actions are in “beta” mode and require registration).

还有Voilà🔮-我们拥有Lighthouse的工作流程！ 假设您的回购中启用了GitHub Actions，您应该看到类似以下的内容( 注意：在撰写本文时，GitHub Actions处于“测试版”模式， 需要注册 )。

Clicking on “Actions” will list all workflows currently running and previous.

单击“操作”将列出当前正在运行和之前的所有工作流程。

After following the steps from our basic example, you should see one item on this list. Clicking in will show us Lighthouse results printed to the console.

按照基本示例中的步骤操作后，您应该在此列表上看到一项。 单击将显示“灯塔”结果打印到控制台。

From our configuration, we also have results captured in HTML reports saved as “artifacts”.

从我们的配置中，我们还将在HTML报告中捕获的结果另存为“工件”。

进阶范例 (Advanced Example)

Lighthouse Check Action offers a complete set of bells and whistles by utilizing lighthouse-check NPM module under the hood. There’s so much more we can do with this. Let’s proceed!

Lighthouse Check Action通过使用引擎盖下的lighthouse-check NPM模块提供了一整套的铃声。 我们可以做更多的事情。 让我们继续吧！

拉取请求注释 (Pull Request Comments)

By utilizing this feature, comments are posted with Lighthouse results on every commit. We can do so by following the steps below.

通过使用此功能，每次提交时，评论将与Lighthouse结果一起发布。 我们可以按照以下步骤进行操作。

1. Create a new user or find an existing one to act as a “bot”.
   创建一个新用户或找到一个现有的用户充当“机器人”。

2. Create a personal access token from this user account.

   从此用户帐户创建个人访问令牌 。

3. Create a GitHub secret to hold the encrypted value from above. In our example we name it LIGHTHOUSE_CHECK_GITHUB_ACCESS_TOKEN.

   创建一个GitHub机密以从上方保存加密后的值 。 在我们的示例中，我们将其命名为LIGHTHOUSE_CHECK_GITHUB_ACCESS_TOKEN 。

4. Update our workflow file with the diff shown below.
   使用下面显示的差异更新我们的工作流文件。
5. Commit and push.
   提交并推动。

with:
+  accessToken: ${{ secrets.LIGHTHOUSE_CHECK_GITHUB_ACCESS_TOKEN }}
  outputDirectory: /tmp/artifacts

With this, we’ve created a bot to post Lighthouse results on pull requests 💥!

这样，我们创建了一个机器人，可以在请求请求中发布Lighthouse结果Lighthouse！

S3报告上传 (S3 Report Uploads)

In our example we persist results by uploading reports as artifacts in our workflow. This solution could be sufficient in some cases, but artifacts aren’t stored permanently. In order to view reports, we need to navigate into the workflow and manually download reports from the artifact view.

在我们的示例中，我们通过将报告作为工件上传到工作流程中来保留结果。 在某些情况下，此解决方案可能就足够了，但不会永久存储工件。 为了查看报告，我们需要导航到工作流程并从工件视图手动下载报告。

But what if we want a more dependable way of storing and referencing reports? This is where the S3 feature comes into play. We can configure AWS S3 storage by following the below steps.

但是，如果我们想要一种更可靠的存储和引用报告的方式呢？ 这就是S3功能发挥作用的地方。 我们可以按照以下步骤配置AWS S3存储。

1. Create an AWS account if you don’t already have one.

   如果您尚未创建一个AWS账户 ，请创建一个。

2. Create an S3 bucket if you don’t already have one.

   如果您还没有一个S3存储桶 ，请创建一个。

3. Acquire an AWS access key id and secret access key.

   获取AWS访问密钥ID和秘密访问密钥 。

4. Create GitHub secrets for these two values. In our example we’ll use LIGHTHOUSE_CHECK_AWS_ACCESS_KEY_ID and LIGHTHOUSE_CHECK_AWS_SECRET_ACCESS_KEY, respectively.

   为这两个值创建GitHub机密 。 在我们的示例中，我们将分别使用LIGHTHOUSE_CHECK_AWS_ACCESS_KEY_ID和LIGHTHOUSE_CHECK_AWS_SECRET_ACCESS_KEY 。

5. Add the bucket name and region (example: us-east-1) as GitHub secrets: LIGHTHOUSE_CHECK_AWS_BUCKET and LIGHTHOUSE_CHECK_AWS_REGION.

   添加存储桶名称和区域 (例如： us-east-1 )作为GitHub机密： LIGHTHOUSE_CHECK_AWS_BUCKET和LIGHTHOUSE_CHECK_AWS_REGION 。

Next, we’ll update our configuration with the following diff.

接下来，我们将使用以下差异更新配置。

with:
  accessToken: ${{ secrets.LIGHTHOUSE_CHECK_GITHUB_ACCESS_TOKEN }}
+  awsAccessKeyId: ${{ secrets.LIGHTHOUSE_CHECK_AWS_ACCESS_KEY_ID }}
+  awsBucket: ${{ secrets.LIGHTHOUSE_CHECK_AWS_BUCKET }}
+  awsRegion: ${{ secrets.LIGHTHOUSE_CHECK_AWS_REGION }}
+  awsSecretAccessKey: ${{ secrets.LIGHTHOUSE_CHECK_AWS_SECRET_ACCESS_KEY }}

In our next commit and push, reports are automatically uploaded to S3 ✅! We also have a them linked in our PR comments.

在我们的下一次提交和推送中，报告将自动上传到S3✅！ 我们的PR评论中也链接了它们。

松弛通知 (Slack Notifications)

What’s a new feature in a DevOps workflow without Slack notifications? A sad one indeed. Let’s ramp things up by adding notifications to a Slack channel for our whole team to see. We can accomplish this in the below steps.

没有Slack通知的DevOps工作流程中的新功能是什么？ 确实是一个悲伤的人。 让我们通过在Slack频道中添加通知以使整个团队都可以看到的方式来提高工作效率。 我们可以通过以下步骤完成此操作。

1. Create an “Incoming Webhook” in your Slack workspace and authorize a channel.

   在您的Slack工作区中创建一个“传入Webhook”并授权频道 。

2. Add the Webhook URL as a GitHub secret — LIGHTHOUSE_CHECK_WEBHOOK_URL.

   将Webhook URL添加为GitHub机密 — LIGHTHOUSE_CHECK_WEBHOOK_URL 。

3. Add GitHub data and the Webhook URL to our configuration with the diff below. The GitHub data will be rendered in our notifications. We pass GitHub data through configuration with the GitHub “context”.

   使用下面的差异将GitHub数据和Webhook URL添加到我们的配置中。 GitHub数据将在我们的通知中呈现。 我们通过GitHub “ context”配置传递GitHub数据。

with:
  accessToken: ${{ secrets.LIGHTHOUSE_CHECK_GITHUB_ACCESS_TOKEN }}  +  author: ${{ github.actor }}
  awsAccessKeyId: ${{ secrets.LIGHTHOUSE_CHECK_AWS_ACCESS_KEY_ID }}
  awsBucket: ${{ secrets.LIGHTHOUSE_CHECK_AWS_BUCKET }}
  awsRegion: ${{ secrets.LIGHTHOUSE_CHECK_AWS_REGION }}
  awsSecretAccessKey: ${{ secrets.LIGHTHOUSE_CHECK_AWS_SECRET_ACCESS_KEY }}
+  branch: ${{ github.ref }}
  outputDirectory: /tmp/artifacts
+  sha: ${{ github.sha }}
+  slackWebhookUrl: ${{ secrets.LIGHTHOUSE_CHECK_WEBHOOK_URL }}
  urls: 'https://www.foo.software,https://www.foo.software/contact'

Our next commit and push introduces Slack notifications! The “Lighthouse audit” link in the below screenshot navigates to the S3 report as configured✨.

我们的下一次提交和推送将引入Slack通知！ 以下屏幕截图中的“灯塔审核”链接导航到已配置的S3报告report。

保持历史记录 (Maintaining a Historical Record)

Foo’s Automated Lighthouse Check is tool we can use to manage a historical record of Lighthouse audits. We can connect to it with the Lighthouse Check GitHub! By doing so you can run Lighthouse remotely versus in a local, dockerized GitHub environment. With this we can be assured our Lighthouse results aren't flaky from GitHub infrastructure change. Follow the documented steps to connect with Automated Lighthouse Check.

Foo的自动灯塔检查是我们可以用来管理灯塔审计历史记录的工具。 我们可以使用Lighthouse Check GitHub连接到它！ 这样一来，您可以在本地dockerized GitHub环境中远程运行Lighthouse。 有了这一点，我们可以确信，由于GitHub基础架构的变化，我们的Lighthouse结果并非易事。 请按照记录的步骤连接“自动灯塔检查” 。

现在怎么办？ (What Now?)

You can find a full example from the above in the Lighthouse Check Action documentation. I hope this article can provide a helpful addition to your DevOps workflow! With Lighthouse integrated in a CI/CD pipeline, we can stay fully equipped to ensure high quality in website SEO, performance, accessibility, best practice, and progressive web apps.

您可以在Lighthouse Check Action文档中从上述内容中找到完整的示例。 我希望本文可以为您的DevOps工作流程提供有益的补充！ 通过将Lighthouse集成到CI / CD管道中，我们可以保持设备齐全，以确保网站SEO，性能，可访问性，最佳实践和渐进式Web应用程序的高质量。

翻译自: https://www.freecodecamp.org/news/how-to-use-lighthouse-in-github-actions/