Всем здравствуйте! Меня зовут Михаил Авдеев и я работаю в проекте Облако Mail.ru! Я расскажу о том, как решал задачу ускорения проверки merge request’ов(MR) в нашей команде. Почему вообще это понадобилось? Потому что разработчики ленивы экономят силы и обычно не стремятся брать новые MR на проверку, либо выбирают что попроще. Так что я решил сделать бота, который для каждого MR автоматически расставлял бы приоритеты и назначал проверяющего.
Идея
Сначала мы пытались решить задачу с помощью бота, идею для которого мы почерпнули у команды Календаря. Он должен был выбирать открытые merge request’ы и слать их в рабочий чат. Написали бота на TypeScript и создали чат. Но схема была рабочая, пока команда была небольшой, а когда она разраслась и количество MR увеличилось, люди смотрели на список задач в чате и старались выбрать ту, что поменьше да попроще. В результате я решил делать бота для GitLab, который принудительно распределял бы обязанности в коллективе высокомотивированных и высокоинтеллектуальных работников умственного труда. Заодно бот избавил бы авторов от творческих мук выбора проверяющих для своего кода.
Ещё бот должен был быть универсальным, чтобы им могли пользоваться не только в нашей команде. Для этого требовалось продумать его настройки и интеграцию с сервисом VK Teams. Идея была в том, что бот не только назначает проверяющего для MR, но и шлёт об этом сообщение ему и автору кода.
Решение
У меня уже был опыт создания ботов, поэтому я выбрал знакомые мне технологии: Gitlab CI и Danger-js. Сколько времени у вас может уйти на создание подобного инструмента, не подскажу, всё зависит от вашего CI. Мне нужно было интегрировать бота с VK Teams, а у вас может быть другой мессенджер, Slack или Telegram, к примеру. В настройки я заложил возможность выбирать количество проверяющих для каждого MR, чтобы бот подходил под разные рабочие конвейеры.
Мой бот шлёт в мессенджер такие сообщения:
А в конвейер GitLab — такие:
Также бот позволяет добавлять к каждому MR какой-нибудь тег, чтобы удобно было классифицировать изменения в коде. В нашем проекте, к примеру используется тег need-review. Если в настройках вашего проекта это предусмотрено, вы можете выделить специальный тег, позволяющий пропускать проверку конкретного merge request’а. Также бот должен пропускать запуск, если MR помечен как draft или wip.
Бот интегрирован в нашу внутреннюю платформу Mail Core CI, чтобы его могли использовать многие другие команды в компании, но вы можете приспособить его и под вашу среду. Как это сделано у нас:
# Джоба для вызова dangerjs в пайплайне через нашу обертку (npx ts-node cli danger) .mail-core:job:danger-init: stage: test needs: [] variables: DANGER_ID: "<<required>>" DANGERFILE: "<<required>>" script: - echo "danger:" $([[ -f ./node_modules/.bin/danger ]] && (./node_modules/.bin/danger --version 2>/dev/null || "[--version not found]") || echo "[file not found]") - echo "dangerfile:" $DANGERFILE - time [[ -d cli/command/danger ]] && npx ts-node cli danger ci --dangerfile=$DANGERFILE --id=$DANGER_ID -f # Джоба для вызова ревью рулетки .mail-core:job:review-roulette: extends: .mail-core:job:danger-init variables: ## Минимальное количество Review Approvers REVIEW_ROULETTE_MIN_APPROVERS: 1 ## Ревью будет пропускать указанных ревьюеров REVIEW_ROULETTE_SKIP_APPROVERS: 'first, second' DANGER_ID: "review-roulette" DANGERFILE: "./node_modules/@mail-core/ci/dangerfiles/review-roulette/index.js"
Логика работы бота
При появлении нового merge request’а Gitlab СI автоматически запускает свой runner. Бот просматривает настройки проекта:
const {REVIEW_ROULETTE_LABEL, REVIEW_ROULETTE_MIN_APPROVERS} = process.env; const {mr, approvals, api, metadata} = danger.gitlab; const {repoSlug, pullRequestID} = metadata; const {iid, author, reviewers, web_url, title, description, labels, draft} = mr as MR; const {suggested_approvers, project_id, approved_by, approvals_required} = approvals as Approvals; const mrLink = `[${repoSlug}!${pullRequestID}](${web_url})`; const approvalsCount = approvals_required || Number(REVIEW_ROULETTE_MIN_APPROVERS);
И проверяет, можно ли пропустить проверку (в зависимости от присвоенного тега, количества ревьюеров и т.д.):
const skipReview = draft || isWip || hasApprove || hasSkipReviewLabel || reviewers.length !== 0;
Если пропустить нельзя, то бот берёт список доступных сейчас проверяющих:
// алгоритм подбора рекомендуемых апруверов (у нас он реализован на основе файла CODEOWNERS) const approvers = getSuggestedApprovers();
Случайным образом выбирает нужное количество людей:
// алгоритм выбора ревьюеров на ваше усмотрение const reviewers = getReviewers(approvers, approvalsCount);
и отправляет им сообщения в мессенджеры (если те интегрированы) и в сам MR.
// Достаем из массива ревьеюров только их id (необходимы для отправки в gitlab api) const reviewerIds = reviewers.map(({id}) => id); const reviewerNames = reviewers.map(({name}) => name).join(', '); const reviewerCountText = reviewers.length > 1 ? 'ревьюеров' : 'ревьюера'; // Получаем на основе ревьюеров email const reviewerEmails = await getReviewerEmails(reviewers, api.Users); const mentionedUsers = reviewerEmails.map((v) => `@[${v}]`).join(','); // Добавляем выбранных ревьюеров в MR await api.MergeRequests.edit(project_id, iid, {reviewer_ids: reviewerIds}); // Информируем автора MR о выбраных ревьюерах в VK Teams await communicator.sendMessage( 'author', ` ${REVIEW_ICON} Я подобрал для *${mrLink}* (${title}) ${reviewerCountText}: ${mentionedUsers} ??? `, ); // Информируем ревьюеров в VK Teams await communicator.sendMessage( reviewerEmails, ` ${REVIEW_ICON} Вы выбраны ревьюером ? *${mrLink}: ${title}* ${description} `, ); // Отправляем сообщение о выбранных ревьюера в MR message( `Я подобрал Вам ${reviewerCountText} ? \n` + '\n' + `Встречайте бурными аплодисментами - ${reviewerNames}! ???`, {icon: REVIEW_ICON}, );
А этот фрагмент кода отвечает за обработку ошибок:
// Получаем ссылку на документацию об ошибке const docLink = getDocLink('ci', {fragment: '#review-roulette'}); // Информируем автора MR об ошибке В VK Teams await communicator.sendMessage( 'author', ` ${REVIEW_ICON} Мне не удалось выбрать ревьюеров для ${mrLink} ? ${errorMessage} Подробнее можно почитать в [документации](${docLink}) `, ); // Отправляем ошибку в MR fail( `Мне не удалось выбрать ревьюеров: \n` + `${errorMessage} \n` + '\n' + `Подробнее можно почитать в [документации](${docLink})`, );
Локальный запуск для тестирования
Чтобы не тестировать бота в Gitlab СI, можно запустить его локально и проверить настройки и корректность работы. Так получается гораздо быстрее, потому что иначе придётся создавать тестовый merge request в проекте, ждать его загрузки, пушить и надеяться, что подключение не отвалится. А для локального запуска достаточно нескольких команд.
Первым делом необходимо настроить локальное окружение:
Для этого настройте переменные окружения.
export DANGER_GITLAB_API_TOKEN=токен export DANGER_GITLAB_HOST=урл/репозитория
Ещё вам пригодятся ссылка на merge request, чтобы бот мог брать из него необходимую информацию.
Локальное тестирование запускается командой npx danger pr “ссылка/на/mr”--dangerfile ‘путь/до/файла/с/ботом”. Результат выполнения в консоли:
Интеграция в конвейер
Бот отлажен, пора запускать его в эксплуатацию. Сначала сгенерируем и добавим переменную окружения DANGER_GITLAB_API_TOKEN в ваш проект.
Про генерацию токена можно прочитать тут, а про добавление в проект — тут .
Затем интегрируем бота.
Проблемы и их решение
Первая проблема была в том, что при выполнении в конвейере нескольких скриптов с ботом последний выполняющийся переписывает результаты работы всех предыдущих. Поэтому я добавил в бот индентификатор, передаваемый через переменную окружения.
npx ts-node cli danger ci --dangerfile=$DANGERFILE --id=$DANGER_ID -f
Вторая проблема оказалась посерьёзнее. Авторы DangerJs заявляют поддержку TypeScript, но на самом деле она работает, если вы не пользуетесь модулями. Иначе вот что происходит:
Danger: ⅹ Failing the build, there is 1 fail. ## Failures Danger failed to run `./dangerfiles/review-roulette/index.ts`. ## Markdowns ## Error SyntaxError Cannot use import statement outside a module ./dangerfiles/review-roulette/index.ts:3 import { Communicator } from 'communicator'; ^^^^^^ SyntaxError: Cannot use import statement outside a module at wrapSafe (internal/modules/cjs/loader.js:1001:16) at Module._compile (internal/modules/cjs/loader.js:1049:27) at requireFromString (/Users/mikhail.avdeev/ci/node_modules/require-from-string/index.js:28:4) at /Users/mikhail.avdeev/ci/node_modules/danger/distribution/runner/runners/inline.js:157:68 at step (/Users/mikhail.avdeev/ci/node_modules/danger/distribution/runner/runners/inline.js:52:23) at Object.next (/Users/mikhail.avdeev/ci/node_modules/danger/distribution/runner/runners/inline.js:33:53) at /Users/mikhail.avdeev/ci/node_modules/danger/distribution/runner/runners/inline.js:27:71 at new Promise (<anonymous>) at __awaiter (/Users/mikhail.avdeev/ci/node_modules/danger/distribution/runner/runners/inline.js:23:12) at Object.runDangerfileEnvironment (/Users/mikhail.avdeev/ci/node_modules/danger/distribution/runner/runners/inline.js:118:132) ``` ### Dangerfile ``` --------------------^ ```
Это решается компиляцией TS в JS файлы.
Ещё одна проблема заключалась в том, что бот автоматически сам себя вырезал (используя регулярные выражения).
// 1. Оригинальный TS import {fail, message, warn, danger} from 'danger'; // 2. Преобразование в JS const dangerjs_1 = require('danger'); // 3. Библиотека вырезает импорт регуляркой dangerjs_1 = ?; // 4. Ошибки вызова библиотечных функций dangerjs_1.fail // Error dangerjs_1.message // Error Dangerjs_1.warn // Error
Чтобы среда не «ругалась», я прописал декларации типов и вынес импорт dangerjs в самый верх файла:
import type * as dangerjs from 'danger'; declare const danger: typeof dangerjs.danger; declare const message: typeof dangerjs.message; declare const fail: typeof dangerjs.fail; declare const warn: typeof dangerjs.warn;
Заключение
Как говорил Сальвадор Дали: “Тот кто не хочет никого имитировать, ничего не создаст.”
Поэтому вперед, создавать своих ботов!
