Comments 13
Я настроил себе мощную 32-ядерную машину в облаке, которую обычно держу выключенной. Специальный скрипт мониторит очередь заданий через GitLab API и включает машину, если что-то ждёт выполнения. Через минуту машина поднимается, раннер выполняет все задания, и потом через 10 минут неактивности скрипт снова выключает машину.
Я использую bazel, который сильно параллелизует сборку и выжимает максимум из машины. На shared runner мой проект собирается около часа, а на моей сборочной машине - 5 минут. И при этом мне это почти ничего не стоит, т.к. в выключенном состоянии я плачу только за диск, а включенное состояние долго не длится. Такой вот лайфхак.
А может кто подскажет решение следующей проблемы. Дано: есть ветка master с релизами, прямой push в которую запрещён политикой Gitlab'а, и ветка dev, в которую могут отправлять изменения разработчики. Ветка master отличает от ветки dev только наличием файла gitlab-ci.yml, то есть код в них после слияния идентичный. При push'е в dev настроена сборочная линия (условно, один шаг), которая собирает текущий коммит и при успешной сборке ветка dev автоматически вливается в master (я в Gitlab'е для этого предварительно нажимаю специальную кнопку, включающую такое автоматическое слияние). Проблема в том, что после слияния опять запускается та же самая сборочная линия (шаг сборки + ещё дополнительный шаг — собственно, выкладка собранных артефактов на боевой сервер), а хотелось бы заиспользовать артефакты, оставшиеся после сборки на ветке dev и просто выложить их на боевой сервер (выполнить только шаг 2), так как сама сборка очень долгая — более 40 минут. В результате выкладка даже малейших изменений затягивается часа на полтора-два.
Используйте rules для исключения ненужных шагов в master ветке
Так проблема не в том, чтобы с помощью rules исключить ненужные шаги — это-то как раз легко. Проблема в том, как взять артефакты, собранные в другой ветке по заданию другой сборочной линии с целью выложить их на прод (смысла собирать их повторно нет, так как код идентичен).
https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#access-the-latest-job-artifacts-by-url
не пробовали добавить шаг только для мастер ветки: скачать артефакты конкретного джоба ветки dev? Предварительно загрузив нужные файлы в артефакты, конечно
Если вас не сильно беспокоит тэги ваших финальных сборок (если они вообще тэгируются), то могу предложить такое решение (если я правильно понял вашу задачу): последний шаг в dev ветке заливает ваши артифакты в хранилище (container registry, artifactory), а в мастер ветке через rules запрещаем билд, или переводим билд в мануальный режим. Мастер - только как хранилище рабочего проверенного кода, от которого просто отбранчевываются. По сути какая разница где был создан артефакт, в дев ветке или в мастере, если он сбилдился. А Деплой в прод берет их из хранилища. Только одно условие - в дев ветку должны сливаться все остальные ветки, а то получится расхождение в реальзованных фичах. Но я так понимаю, что у вас данное условие выполняется, ибо вы считаете, что мастер у вас делает бесполезный билд, значит в дев ветке у вас все фичи есть
Про теги я упомянул, потому что на некоторых проектах бранчи и теги в них - метаинформация для системы версионирования артефактов, поэтому зачастую важно в какой ветке был создан артефакт
Попробую этот вариант, наверное. Да, ветка master чисто хранилищем рабочего кода работает. На самом деле, это такая «интеграция» в систему хранения версий заказчика, потому что реальная разработка идёт вообще в другом хранилище и просто периодически сбрасывается в выделенную для нас ветку dev. Тегов тоже нет, так что не страшно.
Как вариант, можно выкачивать artifacts используя API гитлаба:
curl https://example.com/<namespace>/<project>/-/jobs/artifacts/<ref>/download?job=<job_name>Тогда в gitlab-ci.yml в мастере можно проверять хэши коммитов в master и dev (на случай, если в dev уже попал какой-то новый код, который в master'е не должен находиться). Если они равны, то скачивать artifacts из пайплайна ветки dev, если нет, то билдить и использовать свои
Использовать ключевые слова only/except не подойдет? https://docs.gitlab.com/ee/ci/yaml/#only--except
Отличная статья
Как сделать ваши GitLab CI пайплайны быстрее