缓存、共享和调试工作流

8 分钟

在本单元中，你将了解如何优化性能、在作业之间传递数据以及使用日志和令牌对工作流进行故障排除。

若要实现此过程，你将了解如何：

缓存依赖项以提高工作流速度。
在作业间传递项目数据。
启用工作流调试日志记录。
从 GitHub UI 和 REST API 访问工作流日志。
使用安装令牌进行 GitHub 应用身份验证。

使用缓存操作缓存依赖项

生成工作流时，通常需要重复使用相同的输出或将依赖项从一个运行下载到另一个运行。你可以缓存这些依赖项，以便更快、更高效地运行工作流，而不是反复下载这些依赖项。缓存依赖项减少了在工作流中运行某些步骤所需的时间，因为 GitHub 托管的运行程序上的作业每次都会在干净的虚拟环境中启动。

要缓存作业的依赖项，请使用 GitHub 的 cache 操作。此操作会检索你提供的唯一密钥确定的缓存。该操作找到缓存后，它会将缓存的文件检索到你配置的路径。若要使用该 cache 作，需要设置几个特定的参数：

参数	DESCRIPTION	必选
`Key`	指保存和搜索缓存时创建的密钥标识符。	是的
`Path`	指运行器上用于缓存或搜索的文件路径。	是的
`Restore-keys`	如果未找到所需的缓存密钥，则包含要缓存的替代现有密钥。	否

steps:
  - uses: actions/checkout@v2

  - name: Cache NPM dependencies
    uses: actions/cache@v2
    with:
      path: ~/.npm
      key: ${{ runner.os }}-npm-cache-${{ hashFiles('**/package-lock.json') }}
      restore-keys: |
        ${{ runner.os }}-npm-cache-

在以上示例中，path 设置为 ~/.npm，并且 key 包含运行器的操作系统和 package-lock.json 文件的 SHA-256 哈希。在使用 npm-cache 回退并具有多重缓存时，以 ID 作为密钥前缀（此示例中的 restore-keys）会非常有用。

在作业之间传递工件数据

与在工作流中缓存依赖项的想法类似，可以在同一工作流内的作业之间传递数据。可以使用upload-artifact和download-artifact动作来传递数据。依赖于前一个作业的工件的作业必须等待前一个作业成功完成，然后才能运行。如果您有一系列需要根据从之前任务上传的工件按顺序运行的作业，那么这种方法非常有用。例如，job_2 需要 job_1，方法是使用 needs: job_1 语法。

name: Share data between jobs
on: push
jobs:
  job_1:
    name: Upload File
    runs-on: ubuntu-latest
    steps:
      - run: echo "Hello World" > file.txt
      - uses: actions/upload-artifact@v2
        with:
          name: file
          path: file.txt

  job_2:
    name: Download File
    runs-on: ubuntu-latest
    needs: job_1
    steps:
      - uses: actions/download-artifact@v2
        with:
          name: file
      - run: cat file.txt

此示例包含两个作业。 job_1 在 file.txt 文件中写入一些文本。然后它使用 actions/upload-artifact@v2 操作上传此工件并存储数据，以便将来在工作流中使用。 job_2 要求使用 job_1 语法完成 needs: job_1。然后它使用 actions/download-artifact@v2 操作下载该工件，然后输出 file.txt 的内容。

在工作流中启用单步执行调试日志记录

在某些情况下，默认工作流日志无法提供足够的详细信息，无法诊断特定工作流运行、作业或步骤失败的原因。在这些情境中，可以为两个选项启用更详细的调试日志：运行和步骤。通过将需要对存储库进行 admin 访问的两个存储库机密设置为 true，启用此诊断日志记录。

若要启用运行诊断日志记录，请将包含工作流的存储库中的机密设置为 ACTIONS_RUNNER_DEBUGtrue。
要启用单步执行诊断日志记录，请将包含工作流的存储库中的 ACTIONS_STEP_DEBUG 机密设置为 true。

访问 GitHub 中的工作流日志

当你考虑成功的自动化时，你的目标是花最少的时间查看自动化内容，以便你可以专注于相关的内容。但有时事情没有按计划进行，你需要回顾所发生的事情。调试过程可能会令人沮丧。

GitHub 具有明确的结构化布局，可帮助你在作业之间快速移动，同时保留当前调试步骤的上下文。

若要查看 GitHub 中运行的工作流日志：

在存储库中，转到“操作”选项卡。
在左窗格中，选择工作流。
在工作流运行列表中，选择该运行。
在 “作业”下，选择作业。
读取日志输出。

如果在工作流中运行了多个运行，可以在选择工作流后选择状态筛选器，并将其设置为 “失败 ”，以仅显示该工作流中失败的运行。

从 REST API 访问工作流日志

除了通过 GitHub 查看日志之外，还可以使用 GitHub REST API 查看工作流运行的日志、重新运行工作流，甚至取消工作流运行。若要使用 API 查看工作流运行的日志，请向日志终结点发送 GET 请求。请记住，拥有存储库读取权限的任何人均可使用此终结点。如果存储库为专用，则必须使用具有 repo 作用域的访问令牌。

例如， GET 查看特定工作流运行日志的请求遵循以下路径：

GET /repos/{owner}/{repo}/actions/runs/{run_id}/logs

确定何时使用 GitHub 应用中的安装令牌

在帐户上安装 GitHub 应用后，可以通过将 installation access token 用于 REST 和 GraphQL API 请求以应用安装的形式对其进行身份验证。此步骤允许应用访问安装拥有的资源，前提是应用被授予了所需的存储库访问权限和权限。应用安装发出的 REST 或 GraphQL API 请求归因于应用。

在以下示例中，将 INSTALLATION_ACCESS_TOKEN 替换为安装访问令牌：

curl --request GET \
--url "https://api.github.com/meta" \
--header "Accept: application/vnd.github+json" \
--header "Authorization: Bearer INSTALLATION_ACCESS_TOKEN" \
--header "X-GitHub-Api-Version: 2022-11-28"

还可以使用安装访问令牌对基于 HTTP 的 Git 访问进行身份验证。应用必须具有 Contents 存储库权限。然后，可以使用安装访问令牌作为 HTTP 密码。

将示例中的安装访问令牌替换为 TOKEN ：

git clone https://x-access-token:TOKEN@github.com/owner/repo.git

反馈

此页面是否有帮助？