Хотите автоматизировать проверку кода? Настройте Danger JS для неподдерживаемых ЭК

На примере Google CloudBuild

Что такое Опасный JS?

Вы можете пропустить этот раздел, если вы уже знакомы с Danger JS.

Danger JS — это инструмент сборки с открытым исходным кодом, который позволяет разработчикам программного обеспечения автоматизировать обычные рутинные проверки кода. Используя Danger JS, мы можем автоматически запустить набор правил в отношении вашего запроса на включение (PR) и оставить комментарий для проверки кода.

Он автоматизирует повторяющиеся и тривиальные комментарии проверки кода, такие как:

Это большое PR, пожалуйста, рассмотрите возможность его разбивки, чтобы мы могли эффективно его просмотреть.

or

Пожалуйста, обновите файл журнала изменений.

Это помогает разработчикам сосредоточиться на проверке проблемы, которую пытается решить PR, а не отвлекаться на рутинную проверку кода.

Пример кода

Чтобы лучше понять, как это работает, давайте возьмем в качестве примера распространенный вариант использования: Что делать, если мы хотим оставить комментарий, если запрос на вытягивание слишком большой?

Вы можете написать функцию JS, используя Danger JS, чтобы выполнить этот вариант использования:

Если количество строк, измененных в запросе на вытягивание, превышает произвольное значение bigPRThreshold, оставьте комментарий «предупреждение» в запросе на вытягивание.

Настройка опасного JS

Ниже я суммирую шаги, связанные с настройкой Danger JS в вашем CI.

• Установите Danger, запустив yarn add danger —dev или npm install --save-dev danger.
• Создайте dangerfile и включите его в корневую папку репозитория. Это может быть dangerfile.ts или dangerfile.js.
• Настройте бота GitHub и/или создайте токен GitHub с достаточными правами доступа, чтобы комментировать, одобрять или отклонять запрос на вытягивание.
• Обратитесь к этому списку инструкций по настройке, которым вам необходимо следовать в зависимости от используемого вами ЭК.

Что делать, если мой ЭК не поддерживается?

Например, если вы хотите использовать Danger JS во внутренней CI вашей компании или Google Cloud Build. На момент написания Google Cloud Build не является поддерживаемым CI.

У нас есть два варианта для этого:

• Contribute обратно в Danger.
• Используйте «ручной режим» Danger,ооб этоммы поговорим в следующих разделах.

1. Напишите свой файл опасности

Начните с установки опасности. Мы будем использовать npm для нашего примера.

npm install --save-dev danger

Импортируйте то, что нам нужно, из нашего пакета Danger.

import {danger, warn, markdown} from 'danger';

Создайте наш dangerfile.ts. Мы реализуем следующие функции:

• reviewLargePR()То же, что и в предыдущем примере кода
• ensurePRHasAssignee() Отклонить PR, если нет правопреемника.

Наш dangerfile.ts:

2. Проведите локальное тестирование с помощью warning-pr

Мы можем протестировать наш dangerfile локально, используя danger-pr.js. Это не оставит комментарий к запросу на вытягивание. Он распечатает ожидаемые PR-комментарии в терминале. Эта опция позволяет нам отлаживать dangerfile локально, не спамя комментариями к реальному PR.

Запустите следующую команду в корневой папке вашего репозитория, в той же папке, что и dangerfile.ts:

# Your GitHub API token
export DANGER_GITHUB_API_TOKEN=<yourtoken>
node_modules/danger/distribution/commands/danger-pr.js https://github.com/danger/danger-js/pull/1192

В нашем примере выше мы используем репозиторий GitHub public PR to Danger JS. На момент написания этого PR было изменено около 7000 строк. Это число является большим в соответствии с правилами нашего Dangerfile.

Наш вывод покажет, что PR большой:

3. Запускаем сhazard-ci, используя «Ручной режим»

Danger может поддерживать ЭК, которых нет в их текущем поддерживаемом списке, используя их «ручной режим».

Запуск CI-команды Danger

Теперь, когда наш файл опасности работает должным образом, давайте запустим его с помощью danger-ci локально. Эта команда оставит комментарий к PR, который мы указываем.

ℹ️ Убедитесь, что вы настроили необходимый доступ к GitHub при запуске команды CI.

Установите переменные среды

Мы можем включить ручной режим, установив необходимые переменные среды.

Установите имя вашего ЭК:

# Replace with your unsupported CI's name, e.g. CloudBuild
export DANGER_MANUAL_CI=<UNSUPPORTED_CI_NAME>

Укажите свой репозиторий GitHub:

# Replace with your GitHub repository
export DANGER_MANUAL_GH_REPO=<githuborg/githubrepo>

Установите свой токен доступа к GitHub API, если вы еще этого не сделали:

# Replace with your GitHub API token
export DANGER_GITHUB_API_TOKEN=<yourtoken>

Запустите команду Danger CI

Теперь, когда мы установили необходимые переменные среды👆, запустите команду danger-ci:

DANGER_MANUAL_PR_NUM=<PR Number> node_modules/danger/distribution/commands/danger-ci.js

Переменная окружения DANGER_MANUAL_PR_NUM — это номер PR, который мы хотим, чтобы Danger проверил. Например, если ваш PR: https://github.com/danger/danger-js/pull/1192, переменная среды будет DANGER_MANUAL_PR_NUM=1192.

Пример

ℹ️ Обратите внимание, что у нас есть возможность написать сценарий оболочки, который запускает все команды в этом примере, вместо того, чтобы запускать команды по одной.

Давайте возьмем публичный запрос на извлечение GitHub, который я настроил в качестве примера.

• Репозиторий — ardydedase/danger-example.
• Пример PR — https://github.com/ardydedase/danger-example/pull/1. Обратите внимание на наш PR номер 1.
• Мы будем использовать тот же dangerfile, который проверяет, не слишком ли большой PR и есть ли у него правопреемник. Посмотрите наш dangerfile.ts в нашем репозитории примеров.

Давайте настроим наши переменные среды:

# Replace with your unsupported CI's name, e.g. CloudBuild
export DANGER_MANUAL_CI=MyCI
# Replace with your GitHub repository
export DANGER_MANUAL_GH_REPO=ardydedase/danger-example
# Replace with your GitHub API token
export DANGER_GITHUB_API_TOKEN=<yourtoken>

Затем запустите команду danger-ci с номером PR, который в этом примере равен 1:

DANGER_MANUAL_PR_NUM=1 node_modules/danger/distribution/commands/danger-ci.js

В нашем примере PR завершается ошибкой, потому что для PR не назначен пользователь.

PR-комментарий на GitHub будет таким:

☝️ Для этой демонстрации я использую свой личный токен GitHub, поэтому в PR отображается мое имя пользователя. В идеале мы должны настроить бота GitHub.

Мы проделаем те же шаги в нашем неподдерживаемом CI: установим переменные среды и запустим команду danger-ci. Мы рассмотрим это в следующем разделе. 👇

4. Запустите Danger локально с неподдерживаемым CI (Google CloudBuild).

После тестирования нашего файла опасности на шаге 3 мы теперь готовы настроить Danger с нашим неподдерживаемым CI.

Мы будем использовать Google CloudBuild в качестве нашего CI в нашем примере, потому что:

• На момент написания Google CloudBuild еще не поддерживался CI в Danger JS.
• У него есть инструмент CLI Local Cloud Builder, который мы можем использовать для локального тестирования нашей конфигурации сборки YAML.

Предварительные требования Google Cloud

Нам понадобится наш инструмент CLI CloudBuild, чтобы протестировать нашу сборку Danger с Google Cloud локально. Пожалуйста, обратитесь к документам, указанным ниже:

• Предварительное условие: убедитесь, что вы установили Google Cloud CLI. Обратитесь к этому документу.
• Установите CLI Local Cloud Builder. Нам это понадобится для запуска cloud-build-local.

Файл конфигурации CloudBuild

Давайте создадим наш файл конфигурации:

ℹ️ Замените GITHUB_API_TOKEN своим токеном.

Когда мы запускаем cloud-build-local, dryrun включается по умолчанию, если мы не укажем иное. Это дает нам возможность проверить синтаксис нашей сборки, экономя время на тестирование. Давайте начнем с запуска команды cloud-build-local ниже, чтобы убедиться, что в нашем файле конфигурации нет синтаксической ошибки:

cloud-build-local --config=./cloudbuild-local.yaml .

Если приведенная выше команда выполнена успешно, вывод будет таким:

Давайте теперь установим флаг dryrun в false, чтобы запустить сборку опасности локально:

cloud-build-local --config=./cloudbuild-local.yaml --dryrun=false .

👆 Вышеуказанная команда будет выполнена через несколько минут. Загрузка образа Docker узла займет больше всего времени.

Успешная сборка покажет аналогичный вывод ниже:

И он также должен оставить PR-комментарий:

5. Настройка Google Cloud

Теперь, когда наша локальная конфигурация работает должным образом, мы можем использовать ту же конфигурацию в нашей рабочей настройке Cloud Build.

Конфигурация для производственной среды

Наша производственная установка почти такая же, за исключением того, что мы получаем номер PR из CloudBuild. Вместо жесткого кодирования мы назначим $_PR_NUMBER на DANGER_MANUAL_PR_NUM.

Наша команда Danger CI будет:

DANGER_MANUAL_PR_NUM=$_PR_NUMBER node_modules/danger/distribution/commands/danger-ci.js

Мы также должны хранить наш токен GitHub API в диспетчере секретов Google Cloud или в любом диспетчере «секретов», который вы используете.

Если мы используем менеджер Google Secrets, нам нужно будет обновить нашу конфигурацию сборки, чтобы использовать его:

availableSecrets:
  secretManager:
    - versionName: projects/$PROJECT_ID/secrets/<my-github-token>/versions/1
      env: DANGER_GITHUB_API_TOKEN

Замените <my-github-token> своим секретным именем.

Наша конфигурация сборки с использованием номера запроса на слияние $_PR_NUMBER и секрета от Secrets Manager:

Настройка триггера CloudBuild

Последний шаг — настроить наш триггер CloudBuild, чтобы убедиться, что он работает должным образом.

В Google Cloud Console, создав новый триггер в CloudBuild:

При создании триггера убедитесь, что вы выбрали «Pull request» в качестве события. Это дает нашему файлу конфигурации доступ к $_PR_NUMBER. Если мы этого не сделаем, $_PR_NUMBER вернет пустую строку.

Выберите Репозиторий в качестве местоположения для нашего файла конфигурации. Указываем путь к нашему конфигурационному файлу сборки.

Остальные поля ввода можно оставить как есть.

Это все, что нам нужно. Теперь у вас есть хорошая настройка Google CloudBuild с автоматическими проверками кода на основе Danger JS!

ℹ️ Несмотря на то, что мы пишем наш Dangerfile с помощью TypeScript или JavaScript, Danger JS может работать с любой кодовой базой независимо от языка программирования.

Вы можете найти репозиторий GitHub здесь для справки: