Одна из вещей, которые мне нравятся в разработке программного обеспечения, заключается в том, что если я часто выполняю задачу, я могу вместо этого потратить время на ее автоматизацию, чтобы сэкономить время в долгосрочной перспективе.
Я использовал эту технику во многих вещах как на рабочем месте, так и дома.
Один из таких примеров, когда я что-то автоматизировал, - это когда я хотел купить конкретный дом. Вместо того, чтобы навязчиво проверять сайт, чтобы узнать, доступен ли он, я написал в Node.js веб-парсер, который проверял бы страницу за меня. Он запускался каждые 15 минут на сервере в AWS и отправлял мне СМС, когда дом появился на рынке, с деталями, необходимыми для его резервирования.
Все эти разговоры об автоматизации подводят меня к тому, над чем я работал в последнее время, а именно к автоматизации общей обратной связи по запросам на вытягивание.
Зачем автоматизировать обратную связь по запросу на вытягивание?
Когда вы поднимаете запрос на вытягивание, чем быстрее вы получите обратную связь, тем быстрее он может быть решен. Поэтому стоит учитывать, что бот, который обеспечивает обратную связь путем анализа кода, всегда будет быстрее человека.
Еще одна вещь, которую следует учитывать, заключается в том, что, когда вы решаете автоматизировать обратную связь с запросом на вытягивание, вы по доверенности также кодифицируете передовые методы своей команды. Это может положительно повлиять на ваш код, поскольку сократит количество случаев, когда код, не соответствующий вашим лучшим практикам, будет пропущен во время обычной проверки.
Последняя причина автоматизации обратной связи по запросу на вытягивание заключается в том, что обратная связь от бота несет в себе эмоциональный отклик, отличный от отклика, полученного от коллеги. Бот не собирается лично атаковать чужой код, так что это может положительно повлиять на моральный дух.
При этом автоматизацию обратной связи по запросу на вытягивание следует использовать параллельно с проверками, проводимыми людьми. Автоматизация сосредоточена на применении передовых методов вашей команды, в то время как обычная проверка выявляет проблемы с общим подходом к решению проблемы.
Настройка Danger.js для обратной связи по запросу на вытягивание
Для начала я собираюсь объяснить, как мы можем настроить Danger.js в репозитории GitHub. В этом первом случае он просто выведет сообщение по запросу на вытягивание со списком файлов, которые были изменены.
Первоначальная настройка Danger.js
Первым шагом к настройке опасности в вашем проекте является создание новой ветки, я обычно делаю это в интерфейсе командной строки.
git checkout -b danger
Создав нашу ветку, нам нужно установить danger из npm.
npm install danger --save-dev
Установив Danger.js, теперь вам нужно будет создать файл опасный в корне вашего проекта. Для этого мы можем использовать либо JavaScript, либо TypeScript, с опасным файлом .js, используемым для JavaScript, и опасным файлом.ts. Основное преимущество, которое я увидел от использования TypeScript здесь, заключается в том, что определения типов, предоставляемые с модулем узла, намного лучше предоставляют вам информацию об API, чем документация.
dangerousfile.ts / dangerousfile.js
import {message, danger} from "danger"
const newFiles = danger.git.created_files.join("- ")
message("New Files in this PR: \n - " + newFiles);
Настройка действия GitHub
Следующим шагом является настройка действия GitHub для запуска Danger.js при возникновении запроса на перенос.
Для этого нам нужно создать рабочий процесс. Мы делаем это, создавая файл Yaml в каталоге .github/workflows. Пример рабочего процесса приведен ниже:
name: Danger JS
on: [pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@master
- name: Use Node.js 12.x
uses: actions/setup-node@v1
with:
node-version: 12.x
- name: Danger
run: npx danger ci
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Если мы разбиваем рабочий процесс на ключевые части:
- name: имя действия github, которое будет отображаться в запросе на перенос.
- on: при запуске действия, в нашем случае при создании или изменении запроса на перенос.
- jobs: список задач, которые будут запущены, в данном случае мы указываем одно задание с названием «test».
- шаги: шаги, которые будут выполняться действиями GitHub, в данном случае проверка репозитория, настройка Node.js и последующее использование его для обнаружения опасности.
Бегущая опасность по запросу на вытягивание
Настроив как Danger.js, так и рабочий процесс Github Action, теперь мы можем протестировать это в GitHub, подняв запрос на перенос с помощью нашей ветки.
После создания нашего запроса на вытягивание нам нужно будет подождать пару минут, пока действие будет запущено, а затем мы увидим отзыв о PR, опубликованный ботом действий github.
Рецепты других действий Danger.js
В начальной настройке мы просто попросили Danger.js оставить комментарий со списком новых файлов, добавленных запросом на перенос. Хотя хороший пример настройки имеет ограниченную полезность, в этом разделе мы перечислим еще несколько рецептов, которые вы можете использовать с Danger.js, чтобы сделать его более полезным.
Убедитесь, что package-lock.json обновляется, если package.json изменяется.
Когда новый пакет узла устанавливается из npm, это приводит к изменению файлов package.json и package-lock.json. Оба они должны быть зафиксированы в репозитории, поэтому эта проверка гарантирует, что вы не забудете зафиксировать файл блокировки, если package.json изменился.
Пример кода
const packageChanged = danger.git.modified_files.includes('package.json');
const lockfileChanged = danger.git.modified_files.includes('package-lock.json');
const packageChanged = danger.git.modified_files.includes('package.json');
const lockfileChanged = danger.git.modified_files.includes('package-lock.json');
if (packageChanged && !lockfileChanged) {
warn(`Changes were made to package.json, but not to package-lock.json - <i>'Perhaps you need to run `npm install`?'</i>`);
}
Вывод на GitHub
Посмотреть рецепт на GitHub: https://github.com/jonathan-fielding/danger-js-example/pull/2
Поощряйте небольшие пиарщики
Человеку сложно точно проанализировать большие запросы на вытягивание, потому что бывает сложно отслеживать все разные вещи, которые изменились, и то, как они соотносятся друг с другом. Чтобы побудить вашу команду писать небольшие запросы на вытягивание, вы можете заставить Danger.js публиковать предупреждение, если запрос на вытягивание слишком длинный.
Пример кода
import {warn, danger} from "danger"
const bigPRThreshold = 600;
if (danger.github.pr.additions + danger.github.pr.deletions > bigPRThreshold) {
warn('Big pull request, please keep small to make it easier to review');
}
Вывод на GitHub
Посмотреть рецепт на GitHub: https://github.com/jonathan-fielding/danger-js-example/pull/3
Поощряйте полезные сообщения о фиксации
При работе над проектами, такими как библиотеки JavaScript, которые семантически версированы, может быть полезно, чтобы ваши сообщения о фиксации следовали аналогичной структуре. Это поможет вам вспомнить, как ваш следующий выпуск должен управлять версиями на основе сообщений о фиксации с момента последнего выпуска.
Форматы сообщений фиксации могут быть довольно легко реализованы с помощью Danger.js, проверив сообщения фиксации в PR.
Пример кода
import {fail, danger} from "danger"
danger.git.commits.forEach(commit => {
if (!commit.message.match(/^(feat:)|(fix:)|(major:)|(chore:)/g)) {
fail(`Commit message '${commit.message}' does match the correct format`);
}
})
Вывод на GitHub
Посмотреть рецепт на GitHub: https://github.com/jonathan-fielding/danger-js-example/pull/4
Применение проверок Danger.js
После настройки проверок Danger.js рекомендуется обеспечить выполнение проверок состояния Danger.js, прежде чем код можно будет объединить в вашу основную ветку.
Для этого вам нужно перейти к настройкам репозиториев на GitHub. Затем вы хотите выбрать правило добавления, а затем включить для ветви «Требовать прохождения проверки статуса перед объединением».
Подведение итогов
Завершая этот пост, я просто хотел сказать, что, надеюсь, из предоставленных мной рецептов вы увидите, что все, что вы делаете с Danger.js, - это просто JavaScript.
На самом деле это означает, что вы можете очень быстро написать гораздо более сложные проверки запроса на вытягивание, а затем воспользоваться API Danger.js для предоставления обратной связи.
Я надеюсь, что вы нашли это полезным, и призываю вас подписаться на меня, чтобы увидеть больше сообщений о кодировании, производительности и доступности.
