Мониторинг GitHub Actions по расписанию

Когда это нужно

Красный workflow виден в GitHub. Запуск, которого не было, заметить сложнее. GitHub предупреждает о задержках и возможных пропусках schedule под нагрузкой. Внешний монитор ждёт результат независимо от того, появился ли запуск в Actions.

Как подключить

1. 1

   Создайте монитор с расписанием 0 2 * * * в UTC либо перенесите своё выражение одновременно в YAML и монитор.

2. 2

   Сохраните адрес пинга в Actions secret TICKWATCH_URL. Workflow должен находиться в основной ветке.

3. 3

   Замените ./job.sh на свою команду, запустите workflow вручную для проверки и настройте запас на задержки schedule.

Готовый пример

Пример рассчитан на Linux runner с Bash и curl. TICKWATCH_URL хранится в secrets, а не в коде репозитория. Для каждой независимой задачи используйте отдельный монитор.

name: Scheduled job
on:
  workflow_dispatch:
  schedule:
    - cron: '0 2 * * *' # UTC; match the schedule in TickWatch.
jobs:
  job:
    runs-on: ubuntu-latest
    env:
      TICKWATCH_URL: ${{ secrets.TICKWATCH_URL }}
    steps:
      - uses: actions/checkout@v4
      - name: Signal start
        id: monitor
        shell: bash
        run: |
          RID=$(cat /proc/sys/kernel/random/uuid)
          echo "rid=$RID" >> "$GITHUB_OUTPUT"
          curl -fsS --connect-timeout 3 --max-time 5 --retry 2 --retry-max-time 12 \
            -X POST "$TICKWATCH_URL/start?rid=$RID" >/dev/null 2>&1 || true
      - name: Run job
        id: task
        run: ./job.sh
      - name: Signal result
        if: ${{ always() && steps.monitor.outputs.rid != '' }}
        env:
          RID: ${{ steps.monitor.outputs.rid }}
          RESULT: ${{ steps.task.outcome }}
        shell: bash
        run: |
          suffix=fail
          if [ "$RESULT" = success ]; then suffix=""; fi
          curl -fsS --connect-timeout 3 --max-time 5 --retry 2 --retry-max-time 12 \
            -X POST "$TICKWATCH_URL/$suffix?rid=$RID" >/dev/null 2>&1 || true

Что проверить перед запуском

• Не задавайте запас в несколько секунд: schedule не гарантирует запуск точно в минуту. Оцените обычную задержку и длительность вашего workflow.

• При отмене workflow или потере runner финальный шаг может не выполниться. Отсутствие завершения всё равно проверяется по дедлайну или максимальной длительности.

• В публичных репозиториях schedule может отключиться после 60 дней без активности. Проверяйте состояние workflow, а не только его YAML.

Частые вопросы