Действия GitHub Новый ребенок вокруг блока для автоматизации рабочего процесса. DevOps, ребята, указывают день для этого, так как для них гораздо легче реализовать Ci/CD 🔥 от того же места, которое они проводят свой проект.
В прошлом месяце я работал над созданием рабочего процесса для построения трубопровода развертывания. Проект, который я являюсь частью, это настольное приложение 🖥, построенное на Электрон Отказ
Вы можете думать 🤔, зачем построить приложение для рабочего стола на действиях GitHub? Потому что процесс сборки довольно громоздкий и предпринимает довольно большой кусок разработчиков драгоценного времени 😒. Поскольку мы уже планировали построить CI/CD-CD, мы подумали, что попробуйте с действиями GitHub 😁 (как мы уже размещаем наш проект на Github в частном порядке).
Отказ от ответственности: Этот пост применяется к Linux и Windows Windows и Windows, так как я проверил на тех. Хотя Mac OS Runner не сильно отличается, чем бегун Linux. Вы можете найти больше о них Здесь Отказ
Тестирование рабочего процесса локально
Когда я пробую что-то новое 🐱🏍, первое, что я пытаюсь создать местную среду для проверки ее. Можно ли сделать для действий GitHub? Ответ не является окончательным 🤔. Мы можем использовать наш собственный образ Docker в качестве пользовательского бегуна и проверить его локально на этом локальном образе докера. Мы не можем создать точную среду, чтобы издеваться над рабочим процессом, по крайней мере, я не мог найти никакого решения.
Сложные процессы
Настройка конфигурации YAML для проектов, которые уже используют какую-то каркас, или имеет богатый набор инструментов сборки, действительно легкий ✌. Но когда мы пишем конфигурацию для приложения, где сборка 🏭 требует нескольких процессов, с источниками с разных языков и каркасов, он вроде становится грязным, чтобы отслеживать процесс процесса. Уверен, что вы можете разделить процессы в «Работа» Но у этого есть собственная ловушка 👎, которую я расскажу позже в этом посте.
Действия с рынка
На Github Marketplace есть довольно много Действия написано другими разработчиками 👩💻. Эти действия могут быть написаны двумя способами, используя Конфигурация докера или использовать JavaScript Отказ В то время как Действия JavaScript Беги на всех платформах, действия, написанные в Конфигурация докера Может работать только на Linux. Итак, мы могли бы найти некоторые действия, которые сокращают вашу задачу в половину, но все равно не могут его использовать, только потому, что мы используем бегун Non-Linux.
Настойчивость данных на рабочий процесс
В комплексном построении 🏭 процесс вы можете захотеть пройти некоторую информацию от одной работы на другую, чтобы построить поток. Единственный способ пройти данные между работой, — это использовать Артефакты Github . Они тоже не дешевы. Вы не можете удалить артефакт вручную 😲. Github хранит артефакты для 90 дней для толкающих и вытяжных запросов Отказ Хранение артефактов использует пространство для хранения на GitHub. Кроме того, для частных репозиториев, таких как наш, есть фиксированная сумма «свободных минут» и «хранение», после чего он начнет выставление счетов 💵. Одна хорошая вещь заключается в том, что файлы, загруженные в качестве артефактов, сжаты как «Zip». Таким образом, если вы загружаете файлы журнала или отчеты, вам не может не подумать о хранении, по крайней мере, 😌.
Ограниченная гибкость для действий
Одна конкретная проблема, которую я столкнулся с 🤨, используя действие с рынка, в том, что мы не можем установить Рабочий каталог при выполнении их. Это означает, что эти действия всегда должны выполняться из корневого каталога 😬. Это не имеет значения, если мы создаем единый проект. Но если это Монорепо Затем действия не будут работать, если она не принимает путь каталога в качестве параметра. В моем случае действие приняло путь к каталогу, поэтому я был как-то спасен 😌.
Вот это за сегодня люди. Увидимся, когда я увижу тебя 🐱👤.
Крышка изображения Кредит: калейдико
Оригинал: «https://dev.to/ibrahim13/some-hurdles-of-github-actions-1bp»