Непрерывная интеграция

Встроенные инструменты Deno упрощают настройку конвейеров непрерывной интеграции (CI) для ваших проектов. Тестирование, проверку стиля и форматирование кода можно выполнять с помощью соответствующих команд deno test, deno lint и deno fmt. Кроме того, в конвейерах можно создавать отчёты о покрытии кода на основе результатов тестов с помощью deno coverage.

Настройка базового конвейера

Вы можете настроить базовые конвейеры для проектов Deno в GitHub Actions. Изложенные на этой странице принципы в основном применимы и к другим поставщикам CI, например Azure Pipelines, CircleCI или GitLab.

Создание конвейера для Deno обычно начинается с клонирования репозитория и установки Deno:

name: Build

on: push

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: denoland/setup-deno@v2
        with:
          deno-version: v2.x # Run with latest stable Deno.

Чтобы расширить рабочий процесс, добавьте любые подкоманды deno, которые могут вам понадобиться:

# Install the locked dependencies as a single reproducible step
# (Deno 2.8+). Equivalent to `deno install --frozen` plus npm
# lifecycle-script handling.
- run: deno ci

# 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 ci подробно описано, что именно устанавливается и какие флаги принимает команда.

Кроссплатформенные рабочие процессы

Если вы сопровождаете модуль 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/

git config --system core.autocrlf false
git config --system core.eol lf

Если вы работаете с экспериментальными или нестабильными API Deno, можно включить в матрицу задание, использующее канареечную версию Deno. Это поможет заранее выявить критические изменения:

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: [v2.x]
        canary: [false]
        include:
          - deno-version: canary
            os: ubuntu-latest
            canary: true

Ускорение конвейеров Deno

Сокращение повторений

При кроссплатформенных запусках некоторые этапы конвейера не обязательно выполнять для каждой ОС. Например, создавать один и тот же отчёт о покрытии тестами в Linux, macOS и Windows несколько избыточно. В таких случаях можно использовать условное ключевое слово if в GitHub Actions. В примере ниже показано, как запускать создание отчёта о покрытии кода и его загрузку только на средстве выполнения ubuntu (Linux):

- 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 хранит зависимости локально в каталоге кэша. В конвейере кэш можно сохранять между запусками рабочих процессов, включив параметр cache: true в denoland/setup-deno:

steps:
  - uses: actions/checkout@v4
  - uses: denoland/setup-deno@v2
    with:
      cache: true

Сначала, при запуске этого рабочего процесса, кэш ещё пуст, поэтому такие команды, как deno test, должны будут загрузить зависимости. Однако после успешного выполнения задания кэшированные зависимости сохраняются, и при последующих запусках их можно восстановить из кэша, а не загружать заново.

Для примера предположим, что у вас есть проект, использующий логгер из @std/log:

{
  "imports": {
    "@std/log": "jsr:@std/log@0.224.5"
  }
}

Чтобы обновить эту версию, можно изменить зависимость, а затем локально перезагрузить кэш и обновить файл блокировки:

deno install --reload --frozen=false

После этого вы должны увидеть изменения в содержимом файла блокировки. Когда эти изменения будут зафиксированы и обработаны конвейером, появится новый кэш, который будет использоваться при последующих запусках.

По умолчанию ключ кэша автоматически формируется на основе:

• идентификатора задания GitHub job_id
• ОС и архитектуры средства выполнения
• хеша файлов deno.lock в проекте

Хеш по умолчанию (${{ hashFiles('**/deno.lock') }}), используемый при формировании ключа кэша, можно настроить с помощью параметра cache-hash.

- uses: denoland/setup-deno@v2
  with:
    # setting `cache-hash` implies `cache: true` and will replace
    # the default cache-hash of `${{ hashFiles('**/deno.lock') }}`
    cache-hash: ${{ hashFiles('**/deno.json') }}