持续集成
Deno 的内置工具可以轻松为您的项目设置持续集成 (CI) 流水线。使用相应的命令 deno test、deno lint 和 deno fmt 可以完成测试、代码检查和格式化您的代码。此外，您可以使用流水线中的 deno coverage 从测试结果生成代码覆盖率报告。
设置基本流水线 跳转到标题
您可以在 GitHub Actions 中为 Deno 项目设置基本流水线。本页解释的概念也 Largely 适用于其他 CI 提供商，例如 Azure Pipelines、CircleCI 或 GitLab。
构建 Deno 的流水线通常从检出存储库和安装 Deno 开始
name: Build
on: push
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: denoland/setup-deno@v2
with:
deno-version: v2.x # Run with latest stable Deno.
要扩展工作流，请添加您可能需要的任何 deno 子命令
# Check if the code is formatted according to Deno's default
# formatting conventions.
- run: deno fmt --check
# Scan the code for syntax errors and style issues. If
# you want to use a custom linter configuration you can add a configuration file with --config
- run: deno lint
# Run all test files in the repository and collect code coverage. The example
# runs with all permissions, but it is recommended to run with the minimal permissions your program needs (for example --allow-read).
- run: deno test --allow-all --coverage=cov/
# This generates a report from the collected coverage in `deno test --coverage`. It is
# stored as a .lcov file which integrates well with services such as Codecov, Coveralls and Travis CI.
- run: deno coverage --lcov cov/ > cov.lcov
跨平台工作流 跳转到标题
作为 Deno 模块维护者，您可能想知道您的代码是否在当今使用的所有主要操作系统上都能工作：Linux、MacOS 和 Windows。可以通过运行并行作业矩阵来实现跨平台工作流，每个作业在一个不同的操作系统上运行构建
jobs:
build:
runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [ubuntu-latest, macos-latest, windows-latest]
steps:
- run: deno test --allow-all --coverage cov/
注意：GitHub Actions 在处理 Windows 风格的行尾符 (CRLF) 时存在一个已知的 问题。当在运行在 windows 上的作业的流水线中运行 deno fmt 时，这可能会导致问题。为了防止这种情况，请在运行 actions/checkout@v3 步骤之前，配置 Actions runner 使用 Linux 风格的行尾符
git config --system core.autocrlf false
git config --system core.eol lf
如果您正在使用实验性或不稳定的 Deno API，您可以包含一个运行 Deno Canary 版本的矩阵作业。这可以帮助及早发现重大更改
jobs:
build:
runs-on: ${{ matrix.os }}
continue-on-error: ${{ matrix.canary }} # Continue in case the canary run does not succeed
strategy:
matrix:
os: [ubuntu-latest, macos-latest, windows-latest]
deno-version: [v1.x]
canary: [false]
include:
- deno-version: canary
os: ubuntu-latest
canary: true
加速 Deno 流水线 跳转到标题
减少重复 跳转到标题
在跨平台运行中，流水线的某些步骤不一定需要在每个操作系统上运行。例如，在 Linux、MacOS 和 Windows 上生成相同的测试覆盖率报告有点多余。在这些情况下，您可以使用 GitHub Actions 的 if 条件关键字。下面的示例展示了如何仅在 ubuntu (Linux) runner 上运行代码覆盖率生成和上传步骤
- name: Generate coverage report
if: matrix.os == 'ubuntu-latest'
run: deno coverage --lcov cov > cov.lcov
- name: Upload coverage to Coveralls.io
if: matrix.os == 'ubuntu-latest'
# Any code coverage service can be used, Coveralls.io is used here as an example.
uses: coverallsapp/github-action@master
with:
github-token: ${{ secrets.GITHUB_TOKEN }} # Generated by GitHub.
path-to-lcov: cov.lcov
缓存依赖项 跳转到标题
随着项目规模的增长，往往会包含越来越多的依赖项。Deno 将在测试期间下载这些依赖项，如果工作流每天运行多次，这可能会成为一个耗时的过程。加速处理速度的常见解决方案是缓存依赖项，以便无需重新下载它们。
Deno 将依赖项本地存储在缓存目录中。在流水线中，可以通过设置 DENO_DIR 环境变量并将缓存步骤添加到工作流来在工作流之间保留缓存
# Set DENO_DIR to an absolute or relative path on the runner.
env:
DENO_DIR: my_cache_directory
steps:
- name: Cache Deno dependencies
uses: actions/cache@v4
with:
path: ${{ env.DENO_DIR }}
key: my_cache_key
首先，当此工作流运行时，缓存仍然为空，并且像 deno test 这样的命令仍然必须下载依赖项，但是当作业成功时，DENO_DIR 的内容将被保存，并且任何后续运行都可以从缓存中恢复它们，而不是重新下载。
上面的工作流中仍然存在一个问题：目前，缓存键的名称硬编码为 my_cache_key，这将每次都恢复相同的缓存，即使一个或多个依赖项已更新。这可能导致在流水线中使用旧版本，即使您已更新了一些依赖项。解决方案是每次需要更新缓存时生成不同的键，这可以通过使用 lockfile 和使用 GitHub Actions 提供的 hashFiles 函数来实现
key: ${{ hashFiles('deno.lock') }}
为了使此方法有效，您还需要在 Deno 项目中拥有一个 lockfile，这在此处详细讨论。现在，如果 deno.lock 的内容发生更改，将创建一个新缓存并在随后的流水线运行中使用。
为了演示，假设您有一个项目使用来自 @std/log 的 logger
import * as log from "jsr:@std/log@0.224.5";
为了增加此版本，您可以更新 import 语句，然后重新加载缓存并在本地更新 lockfile
deno install --reload --lock=deno.lock --frozen=false --entrypoint deps.ts
运行此命令后，您应该看到 lockfile 内容的变化。当提交此内容并通过流水线运行时，您应该会看到 hashFiles 函数保存了一个新缓存，并在随后的任何运行中使用它。
清除缓存 跳转到标题
有时您可能会遇到已损坏或格式错误的缓存，这可能是由于各种原因造成的。可以从 GitHub Actions UI 清除缓存，或者您可以简单地更改缓存键的名称。一种实用的方法是在不必强制更改 lockfile 的情况下执行此操作，是将变量添加到缓存键名称中，该变量可以存储为 GitHub secret，并且可以在需要新缓存时更改
key: ${{ secrets.CACHE_VERSION }}-${{ hashFiles('deno.lock') }}