GitHub Actions: как булев сломал цель релиза

В проекте ai-agents-genkit случилось то, что ломает сердце DevOps-инженеров — релиз не произошёл, хотя кнопка была нажата. Виноват в этом не человеческий фактор, а коварная типизация в GitHub Actions.

Всё началось с workflow’а releasekit-uv.yml. Там есть параметр inputs.dry_run — чекбокс для контроля над релизом. Идея простая: если галочка установлена, делаем проверку без реально опубликованного релиза; если нет — выпускаем официальный релиз с тегами и GitHub Release. Казалось бы, надёжная схема.

Но в реальности при нажатии кнопки с dry_run=false всё равно выполнялась сухая прогонка. Теги создавались виртуально, GitHub Release никогда не появлялся, и разработчики сидели в недоумении. Диагноз стоял замечательный — тихая ошибка типизации.

Проблема скрывалась в строке, где вычисляется переменная окружения DRY_RUN:

inputs.dry_run == 'false'

На поверхности выглядит безобидно, но здесь GitHub Actions совершает невидимый трюк. Параметр inputs.dry_run объявлен как тип boolean — настоящий логический тип. Когда разработчик снимает галочку, значение становится собственно булевым false. А в выражении сравнения это false встречается со строковым литералом 'false' — символами, завёрнутыми в кавычки.

В контексте GitHub Actions выражений false == 'false' возвращает false именно потому, что это разные типы: логическое значение не равно строке. Логика внутри условия берёт эту false и путём трёхместного оператора превращает её в строку 'true'. Итог: DRY_RUN всегда получал значение 'true', независимо от того, что нажал пользователь.

Исправление оказалось элегантным. Нужно было просто сравнивать булев с булевым:

inputs.dry_run && 'true' || 'false'

Теперь логика работает честно: если inputs.dry_run истина, берём 'true'; если ложь, берём 'false'. Типы совпадают, выражение вычисляется корректно.

После патча в pull request #4737 жизненный цикл релиза заработал как надо. Версия v0.6.0 уже может быть выпущена с уверенностью, что галочка в интерфейсе workflow’а будет почтительно выполняться машиной.

Вывод: Boolean-типы кажутся простыми, пока не встретишь их в YAML-выражениях GitHub Actions. Туда же относится любая система с собственным парсером логических значений — всегда проверяй, что тип на одной стороне сравнения совпадает с типом на другой.

И помните, в мире Arch Linux говорят: «это работает» — вот и вся ваша документация 😄