Паттерны переиспользования
Тема дорожной карты · GitHub Actions
Переиспользование — это ключевой аспект автоматизации процессов на платформе GitHub Actions. Оно позволяет разработчикам минимизировать дублирование кода, ускорить процесс онбординга и упростить обновления безопасности. В GitHub Actions существует три основных паттерна переиспользования: составные actions, переиспользуемые workflow и стартовые workflow для новых репозиториев. Каждый из этих паттернов имеет свои особенности и области применения, и правильный выбор паттерна может значительно повысить эффективность работы команды.
Как это работает
GitHub Actions предлагает три основных паттерна переиспользования: составные actions, переиспользуемые workflow и стартовые workflow для новых репозиториев. Составные actions позволяют упаковывать последовательность шагов оболочки или JavaScript в файл action.yml. Это особенно полезно, когда единица переиспользования — несколько последовательных шагов с inputs и outputs. Переиспользуемые workflow, в свою очередь, являются целыми workflow, которые можно вызывать из других workflow. Они подходят для расшаривания целых пайплайнов между репозиториями. Стартовые workflow в .github/workflow-templates предназначены для новых репозиториев и помогают быстро настроить базовые конфигурации.
Когда применять
Составные actions следует использовать, когда требуется переиспользование нескольких последовательных шагов с inputs и outputs. Это особенно полезно для создания модульных и переиспользуемых компонентов в конвейерах CI/CD. Переиспользуемые workflow подходят для расшаривания целых пайплайнов между репозиториями. Это идеально подходит для таких задач, как сканирование безопасности, управление выпусками и развертывание. Стартовые workflow в .github/workflow-templates используются для новых репозиториев, чтобы быстро настроить базовые конфигурации. Они полезны для новых проектов, где требуется быстрое наращивание функционала.
Типичные ошибки
Одной из распространенных ошибок при использовании паттернов переиспользования является создание каскадных цепочек вызовов workflow_call. Это может привести к сложности отладки и управлению зависимостями. Другой распространенной ошибкой является сложность передачи секретов между вызываемыми workflow. Для передачи секретов требуется явное указание secrets: inherit или пересылка секретов на уровне каждого отдельного секрета. Также следует избегать изменения входных параметров в "централизованно-владельческом" workflow, так как это может сломать потребительские репозитории. Вместо этого следует выпускать изменения как новую версию и постепенно заменять старую версию.