Уведомления о результате CI/CD

Депешер может сообщать команде об успехе или ошибке этапа CI/CD. Сборочный процесс отправляет POST-запрос на входящий канал, а получатели задаются в личном кабинете: Email, Telegram, группа Telegram, Пачка или Depesher Desktop.

Ниже — скрипт для runner с Bash и curl. Его можно вызвать как команду этапа в вашей системе CI/CD.

Подготовьте канал и переменные

1. Создайте и подтвердите нужные исходящие каналы.
2. Создайте входящий канал для сборок и свяжите его с выбранными получателями.
3. В настройках CI сохраните его URL как переменную DEPESHER_URL.
4. Если включена защита входящего канала, сохраните токен как секрет DEPESHER_TOKEN. Для канала без защиты переменную можно не задавать.

Передайте эти переменные окружения процессу, который выполняет скрипт. Не выводите их значения в журнал сборки.

Отправьте результат этапа

Замените ./deploy.sh реальной командой своего этапа. В этом примере уведомление относится именно к этой команде, а не ко всему pipeline:

#!/usr/bin/env bash

if ./deploy.sh; then
  stage_status=0
  notification="CI/CD: развёртывание завершено успешно"
else
  stage_status=$?
  notification="CI/CD: ошибка развёртывания, код $stage_status"
fi

headers=(--header 'Content-Type: text/plain')

if [ -n "${DEPESHER_TOKEN:-}" ]; then
  headers+=(--header "Authorization: Bearer $DEPESHER_TOKEN")
fi

if ! curl \
  --fail \
  --silent \
  --show-error \
  --max-time 15 \
  --output /dev/null \
  --request POST \
  "${headers[@]}" \
  --data-binary "$notification" \
  "$DEPESHER_URL"; then
  printf '%s\n' 'Не удалось отправить результат этапа в Депешер' >&2
fi

exit "$stage_status"

Код основной команды сохраняется до HTTP-запроса. Поэтому неуспешное развёртывание останется неуспешным для CI, а ошибка уведомления попадёт в журнал отдельно. Опция --fail позволяет обнаружить HTTP-ошибку при отправке.

Добавьте контекст сборки

В текст полезно включить проект, окружение, версию и ссылку на запуск. Имена соответствующих переменных отличаются у CI-систем — подставьте переменные своего runner. Для единообразного оформления можно передавать JSON и использовать шаблон Депешера.

Как проверить

Запустите тестовый этап с командами true и false вместо развёртывания. Проверьте текст уведомления, историю канала и статус этапа в CI.

Скрипт отправляет сообщение, когда управление доходит до HTTP-запроса. При принудительной остановке runner или потере машины он может не выполниться. Для отмен и результата всего pipeline настройте отдельный завершающий этап средствами своей CI-системы.

Если запрос выполнен, но уведомления нет, откройте диагностику доставки.

Ошибка — в Telegram и Email, успех — только в истории

Для личного канала можно разделить внешнюю доставку результата правилами. Этот вариант требует Python 3 на runner для корректной сериализации JSON. Создайте текстовый шаблон:

{{json.project}} / {{json.environment}}: {{json.event.status}}
Этап: {{json.stage}}
Код: {{json.exit_code}}

Выберите его у канала. В настройках входящего канала снимите все прямые назначения исходящих каналов и сохраните. Это важно и при продолжении первого примера: связанные ранее Email или Telegram иначе будут получать каждое событие, включая успех. Подключите три правила без преобразований с наследованием шаблона:

Порядок	Условие JSON «Поле равно», строка	Важность	Действие доставки
1	event.status = failed	Ошибка	Только подтверждённые Telegram и Email
2	event.status = success	Информация	Не добавлять исходящие каналы: при пустой базе только личная история
Default	Без условий	Предупреждение	Явно выбрать Telegram для неизвестного статуса

Для успеха можно не добавлять действие доставки либо добавить его и оставить список пустым: оба варианта сохраняют базовые связи. В этом примере база пуста, поэтому внешней отправки об успехе нет. При желании выберите свой Desktop в правиле успеха. Если оставить Email базово, он получит и успех, и ошибку; пустое действие и default его не отключат.

В первом скрипте после выполнения команды замените формирование текста и HTTP-отправку следующим блоком. stage_status уже содержит результат основной команды:

if payload=$(python3 - "$stage_status" <<'PY'
import json
import sys

code = int(sys.argv[1])
print(json.dumps({
    "project": "shop",
    "environment": "production",
    "stage": "deploy",
    "event": {"status": "success" if code == 0 else "failed"},
    "exit_code": code,
}, ensure_ascii=False))
PY
); then
  headers=(--header 'Content-Type: application/json')
  if [ -n "${DEPESHER_TOKEN:-}" ]; then
    headers+=(--header "Authorization: Bearer $DEPESHER_TOKEN")
  fi

  if ! curl \
    --fail --silent --show-error \
    --max-time 15 --output /dev/null \
    --request POST \
    "${headers[@]}" \
    --data-binary "$payload" \
    "$DEPESHER_URL"; then
    printf '%s\n' 'Не удалось отправить JSON результата в Депешер' >&2
  fi
else
  printf '%s\n' 'Не удалось сформировать JSON результата' >&2
fi

exit "$stage_status"

project, environment и stage замените контекстом своего этапа. Проверка: с false ожидайте failed, важность «Ошибка» и две внешние доставки; с true — success, «Информация», сообщение в истории без внешних доставок. В обоих случаях код завершения этапа должен сохраниться. Неизвестный строковый статус проверьте отдельно в симуляции, затем HTTP-запросом: он должен выбрать default и Telegram.

В организации вместо исходящих каналов правило добавляет людей/команды к базовым назначениям; каждый задаёт свои способы для входящего канала. Для чтения всех назначенных событий только в ЛК сотрудник оставляет свою личную доставку пустой. Правило не переключает его личные способы отдельно для успеха и ошибки. Если ни база, ни выбранное правило не дают получателей, личные сообщения сотрудникам не создаются. Развилки команд показаны в JSON-рецепте.