Инструменты CI/CD

валидатор GitHub Actionsформатирование, проверка и переход между job

Вставьте workflow YAML, чтобы отформатировать его, пройти по дереву job/step и предпросмотреть черновик matrix или cron перед вставкой.

Автопроверка

YAML workflow

Результат

Всё обрабатывается только в браузере, ничего не отправляется в GitHub или на сервер.

НастройкиОтступ

Генератор matrix (черновик)

Переменные

include (необязательно)

exclude (необязательно)

fail-fastmax-parallel (необязательно)Вставить в job

Нажмите «Сгенерировать предпросмотр», чтобы увидеть фрагмент strategy.matrix.

Генератор расписания cron (черновик)

Cron-выражение (5 полей)Часовой пояс (необязательно)

Нажмите «Сгенерировать предпросмотр», чтобы увидеть фрагмент on.schedule.

Ожидает проверки…

Файл workflow YAML для GitHub Actions обычно ломается уже после push — job без runs-on, значение permissions, которого нет в реальном перечне, или расписание, которое тихо ни разу не сработало. Этот валидатор GitHub Actions находит такие ошибки локально, ещё до запуска run, проверяя структуру, от которой реально зависит CI, а не только общий синтаксис YAML.

Он пригодится, когда вручную редактируется длинный workflow с несколькими job и нужно быстро найти сломанный, когда строится build matrix по разным операционным системам и версиям, когда нужно разобраться со ссылками env, secrets и vars сразу в нескольких step, или когда пишется cron-выражение для on.schedule и важно понять, что именно разрешает сам GitHub Actions.

Почему стоит использовать этот валидатор GitHub Actions

Один рабочий стенд вместо переключения между обычным YAML-линтером, генератором matrix и cron-инструментом, который вообще не знает GitHub Actions.

Форматирование, проверка структуры и навигация по job/step в одном месте

После вставки workflow YAML форматируется, id job и step проверяются по правилу именования, у каждого job проверяется наличие runs-on или uses, значения permissions сверяются с реальным перечнем (id-token допускает только write или none), а одновременное использование взаимоисключающих фильтров вроде branches и branches-ignore помечается отдельно — затем строится кликабельное дерево job/step, которое переносит редактор прямо на нужную строку.

Смотреть правила и ограничения

Отформатированный workflow YAML GitHub Actions рядом с кликабельным деревом навигации по job и step, где выделена ошибка структуры

Видно, где именно сломаются ссылки env, secrets и github

Панель ссылок перечисляет каждое найденное выражение ${{ env.X }}, ${{ secrets.X }}, ${{ vars.X }} и ${{ github.X }} вместе с job и step, к которым оно относится, и отдельно отмечает три задокументированных места сбоя: env нельзя использовать в id или uses шага, secrets нельзя читать напрямую в условии if:, а github нельзя использовать внутри uses:.

Посмотреть, как извлекаются ссылки

Список ссылок env, secrets, vars и github с тремя отмеченными местами, где GitHub Actions действительно выдаёт ошибку

Конструктор cron, который уже знает собственные ограничения GitHub Actions

Панель cron собирает стандартное выражение из пяти полей и сразу применяет ограничения, которые GitHub документирует для триггера schedule: минимальный интервал пять минут, UTC по умолчанию с опциональным часовым поясом IANA, отсутствие псевдонимов вроде @daily и автоматическое отключение после 60 дней без активности в публичном репозитории.

Читать вопросы про расписание

Конструктор cron с минимальным интервалом пять минут, часовым поясом UTC по умолчанию и предупреждением о неподдерживаемом псевдониме GitHub Actions

Три вещи, которые легко пропустить при первом запуске

Стенд делает автоматически гораздо больше, чем видно на панели инструментов.

Вставьте workflow или загрузите пример

Вставьте workflow YAML, скопированный из своего редактора, или загрузите встроенный пример — в нём уже есть триггер schedule, job со strategy.matrix и ссылки env/secrets/github, так что все пять возможностей видно сразу. Автоматическая проверка включена по умолчанию и перезапускается через 350 мс после остановки ввода; ничего никуда не отправляется.

Клик по имени любого job или step в дереве навигации переносит редактор прямо на эту строку — именно это по-настоящему экономит время, когда job в workflow больше пары штук.

Панели matrix и cron — это черновики, а не изменения на лету

Редактирование таблицы переменных matrix или полей cron само по себе никогда не трогает workflow, а только строит предпросмотр. В strategy.matrix или on.schedule ничего не записывается, пока не нажата кнопка «Вставить», а до этого черновик всё равно можно скопировать отдельно.

Заключайте номера версий в кавычки, например node-version: "3.10" — без кавычек YAML прочитает 3.10 как число 3.1 и молча потеряет конечный ноль.
fail-fast по умолчанию равен true, а max-parallel остаётся пустым (без ограничения) — так же, как по умолчанию в самом GitHub Actions.

Читайте отметки риска, прежде чем доверять результату без ошибок

Список ссылок env/secrets/vars/github отмечает именно те места, где GitHub Actions документированно отклоняет выражение, а не догадку обычного линтера. Ctrl/Cmd+Enter запускает повторную проверку, если автозапуск выключен; если продолжить редактирование после результата, копирование и скачивание остаются недоступны до повторной проверки, чтобы никогда не экспортировать устаревший результат.

Фильтр над списком ссылок позволяет показать только env, secrets, vars или github за раз — удобно, когда в workflow много выражений.

Что на самом деле происходит под капотом

Пять возможностей работают вместе, а не как пять разных вкладок.

Форматирование YAML с выбором отступа

Workflow переформатируется с единообразным отступом в два или четыре пробела, поэтому diff в pull request показывает только реально изменённые строки, а не весь файл заново.

Структурные проверки по реальным правилам workflow

id job и step проверяются по требуемому шаблону именования, у каждого job проверяется наличие runs-on или uses, значения permissions сверяются с реальным перечнем, а взаимоисключающие фильтры вроде branches и branches-ignore отмечаются, если оба присутствуют в одном триггере.

Кликабельное дерево навигации по job/step

Дерево отражает реальную структуру job и step в workflow; выбор элемента прокручивает редактор ровно к этой строке, не заставляя вручную считать уровни отступов.

Генератор matrix (матрица заданий) с include, exclude и fail-fast

Постройте таблицу переменных вроде os/версия, добавьте комбинации include или exclude, настройте fail-fast и max-parallel, посмотрите предпросмотр итогового strategy.matrix и вставьте его в выбранный job.

Перечень ссылок env/secrets/vars/github

Каждое выражение ${{ }}, ссылающееся на env, secrets, vars или github, извлекается и перечисляется по job и step, с фильтром, позволяющим оставить только один из этих контекстов.

Генератор фрагментов cron специально для GitHub Actions

Соберите расписание из пяти полей на основе частых пресетов или собственного выражения, посмотрите предпросмотр точной записи on.schedule и вставьте её — собственные ограничения расписания GitHub применяются автоматически, их не нужно запоминать.

Что этот инструмент проверяет, а что сознательно не делает

Знать границы важнее, чем иметь длинный список функций.

Ничего не подключается к GitHub: Этот валидатор GitHub Actions только читает YAML локально. Он никогда не обращается к API GitHub, не делает fork или push репозитория и никогда не запускает и не триггерит workflow — он только форматирует и проверяет вставленный текст, полностью на устройстве пользователя.
Выражения не вычисляются: ${{ github.sha }} или ${{ steps.build.outputs.version }} извлекаются и перечисляются, но не разрешаются в реальное значение времени выполнения. Чтобы протестировать реальное поведение выражений, нужен отдельный движок вычислений — это отдельный инструмент, и здесь его сознательно не имитируют через eval на JavaScript.
Проверка schema — это узкое подмножество, а не аналог actionlint: Структурная проверка охватывает ту часть публичной схемы schemastore.org, которая не зависит от внешних метаданных: id job/step, runs-on/uses, permissions, конфликты фильтров. Она не проверяет типы входных данных action, версии action из Marketplace и не хранит актуальный список поддерживаемых меток runner — такие метаданные устаревают сразу после офлайн-кеширования.
Граф зависимостей не строится: Дерево job/step показывает структуру, а не отрисованный DAG из отношений needs: между job. Если нужен визуальный граф зависимостей, требуется другой вид отображения, который этот инструмент пока не предлагает.
Ограничения расписания задокументированы, но не гарантированы: Конструктор cron применяет опубликованные правила GitHub — минимум пять минут, UTC по умолчанию, отсутствие псевдонимов вроде @daily, — но не может гарантировать, что опциональный часовой пояс в поле timezone будет учтён или что расписание сработает ровно в указанную минуту; сам GitHub указывает на возможные задержки при высокой нагрузке и на автоматическое отключение после 60 дней бездействия репозитория.

Частые вопросы про валидатор GitHub Actions

Ответы опираются на то, что документирует GitHub, а не на догадки.

Настроенный timezone в cron-расписании GitHub Actions действительно применяется?

То, что генерируется, синтаксически корректно — GitHub Actions добавил опциональную поддержку часового пояса IANA для schedule в 2024 году. Но в самих обсуждениях сообщества GitHub есть реальные сообщения о том, что она не применялась на практике. Этот валидатор гарантирует только то, что фрагмент соответствует опубликованному синтаксису, но не то, что планировщик GitHub действительно его применит.

Почему cron-расписание в GitHub Actions не запускается в указанное время?

Несколько реальных причин: файл workflow не находится в ветке по умолчанию, репозиторий был неактивен и GitHub автоматически отключил расписание через 60 дней, либо выражение использует интервал короче задокументированного минимума в пять минут. GitHub также указывает, что запланированные запуски могут задерживаться при высокой нагрузке, особенно около начала часа — этот инструмент проверяет синтаксис cron, но не может гарантировать точное время срабатывания.

GitHub пишет только "you have an error in your yaml syntax", но не понятно, в какой строке ошибка — как её найти?

Вставьте workflow в этот валидатор GitHub Actions: он покажет конкретное имя job или step вместе со строкой и столбцом вместо общего сообщения GitHub. Автоматическая проверка перезапускается через 350 мс после остановки ввода, так что отмеченное место обновляется по мере исправления.

Почему блок with: в reusable workflow выдаёт "Unrecognized named-value: 'env'"?

Потому что контекст env просто недоступен внутри with: — это одно из трёх задокументированных ограничений, которое панель ссылок отмечает напрямую (env также запрещён в id и uses шага). Перенесите значение в env на уровне job или workflow, либо явно передайте его как input в reusable workflow.

Как использовать secrets GitHub Actions внутри условия if?

Не напрямую: secrets нельзя читать прямо внутри условия if:. Сначала присвойте secret переменной env на уровне job или step, а затем проверяйте это значение env в условии if:. Это одно из трёх рискованных мест, которые панель ссылок выделяет для каждой ссылки secrets.*.

Почему номер версии matrix 3.10 превращается в 3.1?

Значение 3.10 без кавычек YAML читает как число 3.1, молча теряя конечный ноль — это особенность разбора YAML, а не ошибка GitHub Actions. Генератор matrix распознаёт значения, похожие на номера версий, и автоматически заключает их в кавычки при вставке сгенерированного strategy.matrix.

Нашли workflow, который этот инструмент оценивает неверно?

Попробуйте этот валидатор GitHub Actions прямо сейчас

Вставьте workflow в этот валидатор GitHub Actions, посмотрите, как обновляются дерево job/step и список ссылок, а затем при необходимости подготовьте черновик matrix или cron.

Всё остаётся в вашем браузере — ничего не загружается, и ни один workflow никогда не запускается.

Вернуться к инструменту Смотреть инструменты CI/CD

Весь разбор происходит локально в браузере.

валидатор GitHub Actionsформатирование, проверка и переход между job