Каков наиболее эффективный способ совместного использования рабочих процессов github в нескольких репозиториях? - PullRequest
1 голос
/ 12 июля 2020

В настоящее время я настраиваю рабочий процесс с действиями Github для своей команды. Однако у меня есть более десятка репозиториев для наших различных микросервисов, и я не хочу просто неуклюже копировать каталог .github / workflows / между каждым из них. Если нам нужно изменить наш рабочий процесс, мне придется скопировать все изменения между каждым репозиторием.

Решение, которое я сейчас рассматриваю, - это просто иметь каталог моих рабочих процессов как подмодуль git. (Изменить: протестировано, и когда ваш каталог рабочих процессов является подмодулем, github не распознает его как содержащий действия)

Есть ли альтернатива этому решению? Существуют ли какие-либо текущие «лучшие практики» для управления этими рабочими процессами?

1 Ответ

2 голосов
/ 12 июля 2020

GitHub недавно добавил шаблоны рабочего процесса для организаций, см. ' Совместное использование шаблонов рабочего процесса в вашей организации '

Что касается альтернатив - вы можете написать свои собственные действия или сценарии оболочки, которые позаботятся как можно больше задач. Хотя вам по-прежнему нужно позаботиться о рабочих процессах, в крайних случаях они могут быть сокращены до проверки и делать все-я-хочу шагов. У сценариев оболочки есть дополнительное преимущество, заключающееся в том, что они могут работать с другими CI, если поддерживается долго выбранная оболочка. рабочие процессы в другие репозитории, но это в основном автоматизирует то, что вы уже делаете. Репозитории, которые использовали / планируют использовать другие сценарии оболочки CI pick. Организации сосредоточены на действиях по выбору одной экосистемы (либо их собственных, либо созданных сообществом). Некоторые люди на форуме поддержки выбрали autopu sh, так как в то время он был наиболее близок к шаблонам. Ничего не могу сказать об использовании шаблонов рабочего процесса - функция была опубликована c всего несколько недель go [на момент написания], так что это не совсем сюрприз.

...