Добавить в корзинуПозвонить
Найти в Дзене
Цифровая Переплавка

💻 GitHub Actions: любая программа — ваш персональный shell

Недавняя находка одного из энтузиастов GitHub Actions переворачивает представление о том, как может выполняться код внутри популярного сервиса автоматизации задач. Оказывается, указать в качестве оболочки (shell) можно совершенно любую исполняемую программу из $PATH, и GitHub беспрекословно будет её использовать. Давайте подробнее разберёмся, почему это интересно, и какие перспективы открываются перед разработчиками и DevOps-инженерами. Привычно, что в GitHub Actions используется стандартный shell по умолчанию: Однако, оказывается, GitHub совершенно спокойно воспримет любой бинарник из вашего пути исполнения $PATH. Для этого достаточно указать в workflow-блоке: - shell: ваша_программа {0}
run: |
# код, который будет передан во временном файле Эта особенность не была подробно задокументирована, а значит, открывает интересные горизонты для изобретательных пользователей. Автор оригинальной статьи демонстрирует сразу несколько «экстремальных» примеров применения такого подхода: 🎯 За
Оглавление

Недавняя находка одного из энтузиастов GitHub Actions переворачивает представление о том, как может выполняться код внутри популярного сервиса автоматизации задач. Оказывается, указать в качестве оболочки (shell) можно совершенно любую исполняемую программу из $PATH, и GitHub беспрекословно будет её использовать. Давайте подробнее разберёмся, почему это интересно, и какие перспективы открываются перед разработчиками и DevOps-инженерами.

🤔 Что произошло?

Привычно, что в GitHub Actions используется стандартный shell по умолчанию:

  • 🐧 Linux и 🍎 macOS — это всегда bash (с флагами --noprofile --norc -eo pipefail).
  • 🪟 Windows — используется PowerShell (pwsh).

Однако, оказывается, GitHub совершенно спокойно воспримет любой бинарник из вашего пути исполнения $PATH. Для этого достаточно указать в workflow-блоке:

- shell: ваша_программа {0}
run: |
# код, который будет передан во временном файле

Эта особенность не была подробно задокументирована, а значит, открывает интересные горизонты для изобретательных пользователей.

🎩 Неожиданное применение

Автор оригинальной статьи демонстрирует сразу несколько «экстремальных» примеров применения такого подхода:

🎯 Запуск C-кода без компиляции вручную

- run: sudo apt install -y tcc
- shell: tcc -run {0}
run: |
#include <stdio.h>
int main() {
printf("Hello, world!\n");
return 0;
}

💡 Любопытный факт:

  • TCC (Tiny C Compiler) — один из самых компактных и быстрых компиляторов языка C. Он способен исполнять код «на лету» без явной предварительной компиляции. Это даёт возможность запускать код прямо из GitHub Actions в реальном времени, что, согласитесь, выглядит крайне необычно и креативно.

🎭 Подмена стандартных утилит

Представьте, что вы случайно (или намеренно!) переопределили бинарник bash:

- run: |
touch ./bash
chmod +x ./bash
echo '#!/bin/sh' > ./bash
echo 'echo hello from fake bash' >> ./bash
echo "${PWD}" >> "${GITHUB_PATH}"

- run: |
echo "this doesn't do what you expect"
shell: bash

В результате вызов bash будет обращаться вовсе не к стандартной оболочке, а к вашему кастомному скрипту. Это демонстрирует гибкость (а также потенциальные риски) такой настройки.

🔐 Вопросы безопасности

Подобная «вольность» может привести к серьёзным размышлениям на тему безопасности. Автор исходной новости справедливо отмечает, что сам факт подобного поведения GitHub Actions весьма неожиданный. Пользователи ожидают, что при указании shell: bash будет всегда вызываться именно стандартный бинарник, а не произвольная программа из $PATH.

С другой стороны, GitHub Actions по умолчанию разрешает довольно много различных возможностей исполнения произвольного кода (например, использование переменной GITHUB_ENV уже даёт широкие возможности для динамического исполнения команд и скриптов). Однако в контексте безопасности, безусловно, важно учитывать, как именно выстраивается порядок выполнения команд, откуда именно запускаются используемые бинарники и как контролируются окружения.

🎓 Совет автора:

  • Следует помнить об этой особенности и при необходимости явно прописывать полные пути к бинарникам, если важно именно такое поведение.
  • Рекомендуется проводить дополнительный аудит workflow-файлов на предмет безопасности и возможных неожиданных последствий.

🛠️ Практическая полезность

На первый взгляд, этот механизм может показаться лишь очередной «занимательной фичей», не имеющей практической пользы. Но на самом деле, возможности здесь гораздо шире:

  • 🔍 Быстрый прототипинг и тестирование: Например, запускать небольшие утилиты и фреймворки для автоматических проверок прямо в workflow.
  • 📦 Расширенные кастомные окружения: Вы можете использовать нестандартные оболочки (например, на Python, Ruby, Go) без лишних сложностей.
  • 🚨 Тестирование безопасности и проникновения: Возможно быстрое развёртывание нестандартных сред, имитирующих реальные сценарии.

Автор статьи считает, что подобные «спрятанные» возможности в GitHub Actions имеют большой потенциал для технических исследований и любопытных инженерных решений. И я с ним абсолютно согласен — чем больше возможностей для гибкого использования инструментов, тем интереснее и эффективнее становится работа.

🔥 Заключение

Фактически GitHub Actions стал ещё одним шагом ближе к универсальной платформе автоматизации, где любые нестандартные и креативные идеи легко находят своё воплощение. Конечно, стоит помнить и о потенциальных подводных камнях такого подхода. Но неоспоримым остаётся одно — GitHub Actions снова сумел удивить нас гибкостью и широтой возможностей.

🌐 Ссылки и источники: