Каковы различия между GitHub Actions и другими инструментами CI, такими как Jenkins? - PullRequest
0 голосов
/ 23 октября 2018

GitHub объявил о новой функции, GitHub Actions .

Я положительно оцениваю преимущества таких инструментов CI, как Jenkins, для автоматического построения или тестирования, которые GitHub Actions предназначена для использования.в будущем.

Наличие хранилища на GitHub и использование внешнего инструмента CI дает огромное преимущество, позволяя перемещать хранилище на другую платформу Git (или даже локально) без переписывания всего процесса CI.С действиями GitHub вы более или менее привязаны к экосистеме GitHub.

Я предполагаю, что интеграция действий GitHub будет более беглой в среде native , но есть ли другие преимуществаили минусы кроме этого?

1 Ответ

0 голосов
/ 20 июня 2019

Я работаю с действиями GitHub на полную ставку уже пару месяцев.

Пока еще рано (июнь 2019 г.), но вот мой список:

Преимущества:

  1. Действия GitHub - это просто последовательные запуски Docker.Очень легко рассуждать и отлаживать.Воспроизведение среды сборки для на основе контейнера Travis возможно , но сложнее.В действиях GitHub это просто docker build docker run.
  2. Отдельные действия в рабочем процессе изолированы по умолчанию.Вы можете использовать совершенно другую вычислительную среду для, скажем, компиляции и тестирования.Travis CI (и я думаю, что другие "традиционные" CI) будут выполнять все "стадии" (действия) в одной вычислительной среде.Опять же, действия GitHub намного проще рассуждать и отлаживать.
  3. Спецификация main.workflow (подмножество HCL и на самом деле просто ориентированный ациклический граф) - это open source .В любом случае, все это довольно тонкая оболочка вокруг Docker, поэтому блокировка платформы, возможно, минимальна.
  4. Существует уже повторных реализаций действий GitHub с открытым исходным кодом, таких как act для локального тестирования.
  5. У вас есть готовый доступ к GitHub API с (несколько ограниченной) аутентификацией из коробки.
  6. Там может быть активным сообществом(рынок?), где люди могут делиться действиями.Например, я повторно использую действия по развертыванию, созданные разными людьми в разных экосистемах.
  7. Направленный ациклический граф (DAG) и визуальный редактор для main.workflow s, возможно, являются хорошим способом моделирования CI / CD вв частности и рабочие процессы в целом.Требуется некоторое привыкание, но хорошо обобщает.
  8. Действия GitHub могут сделать намного больше, чем просто CI!В основном у вас есть весь API в качестве входных и выходных данных.

Недостатки:

Действия GitHub (все еще?) Иногда имеют удивительно фундаментальные ограничения на данный момент (июнь 2019 г.)).

  1. Нет собственного кэширования.Вы получаете image и кеширование слоя (это сложно ), но больше ничего.Для создания артефактов сборки вы должны развернуть свой собственный кеш (через AWS, Azure и т. Д.), Что может быть большой работой.(Вы можете увидеть хакерскую настройку здесь .
  2. Удивительно, но нет поддержки запросов на получение от вилок . Это снова немного сложно , иЭто понятно с точки зрения безопасности, но в настоящее время невозможно выполнить действия а) против секретов принимающего репо форка PR (базы) и / или б) против потенциального результата слиянияPR пиар (это то, что делает Трэвис).Для рабочего процесса, который включает в себя форки, который делает действия GitHub в основном непригодными для использования в качестве инструмента CI / CD.
  3. Одиночная платформа, это просто то, что вы можете запустить в докере, так что некоторые дистрибутивы Linux.Это вряд ли изменится, но может быть приемлемым ограничением.Вы всегда можете добавить действие для вызова других кросс-платформенных сервисов CI / CD.
  4. Документация все еще довольно скудна.Не так много в плане лучших практик или строительных лесов.
  5. Качество и широта опубликованных действий GitHub (по крайней мере, на рынке) все еще довольно низки / ограничены.Посмотрим, сработает ли это.
  6. Отличного способа выполнения юнит-тестов нет.(Я взломал что-то вместе, но я не слишком уверен в этом).
...