Comments 21
artifacts используется и для передачи файлов между stages, и для попадания в downloadable artifacts. Возможно это поменятся, но пока так.
раннеры можно и свои запустить, linux, macos или windows, раннер этот может и не использовать докер вообще, а только локально выполнять команды
поэтому и нужна возможность перетягивать файлы между задачами, но при этом весь репозиторий клонируется на всех задачах
Сюда напишу по ближе к началу :)
Из статьи не очевидно, что артифакт передается через все стадии, т.е. если артифакт получен в compile, то он доступен и в test и в package. (версия Gitlab 14.7.0)
Определяет команды, которые выполняются перед всеми заданиями
before_script выполняется перед script задания, а не всех заданий, по крайней мере размещение before_script за пределами конкретной задачи не рассматривается в статье.
Задачи могут выполняться последовательно, параллельно, либо вы можете задать свой собственный порядок выполнения, создав конвейер.
Не совсем понятно, есть какой-то третий вариант с конвеером? Если я правильно понял, то конвеер получается благодаря этапам (stages), через которые мы можем определять порядок выполнения задач, хотя задачи внутри этапа вроде как выполняются параллельно, и тогда не понятно а можно ли внутри этапа задать последовательность выполнения или нужно вводить новый этап.
В целом статья понравилась, соответствует заголовку.
Подскажите, можно ли иметь единый .gitlab-ci.yml для всех веток?
И еще вопрос, можно как-то динамически формировать имя артефакта?
У меня после сборки получается файл package-${version}-${release}.el7.centos.${arch}.rpm при чем переменные вычисляются в процессе сборки.
если переменные вычисляются, то они могут попасть в переменные окружения и использоваться для формирования имени
нужно учитывать что блок scripts, это команды операционной системы и выбранного шелла, да ведь раннер может быть и на винде и команды могут быть powershell
— нет постоянных ссылок на скачивание последних артефактов (latest, а не номер билда; удобно для скриптов бутстрапа, например)
— вроде бы в последних версиях ручной запуск появился, но нет параметризированного запуска (может и не нужно, можно тот же список серверов забить в файл отдельными ручными работами, но нужно учитывать при проектировании)
— нет работ не привязанных к ветке/репозитарию (из-за этого придется для некоторых вещей сохранить Jenkins)
— нотификации (типа интеграции со слаком) идут вне файла настройки ci
Текущие минусы:
— долго промучился, но команды сборки докера в докере не заработали (ни docker in docker, который не предназначен для систем CI и постоянно в документации Gitlab CI упоминается; ни пробрасывание сокета докера), использую отдельный shell runner для этого.
— кеширует только после успешного завершения работы (например, пока настраиваешь работу каждый раз качает плагины maven)
— медленно (пофайлово?) сохраняет кеш
— нет способа через UI сбросить кеш и посмотреть какие кеши есть. все-таки кеши время от времени приходится сбрасывать
— по ощущениям собирает медленней Jenkins, относительно долго (секунд 15) запускается любая докер-работа с одной командой echo
— нет готового рецепта для Java/Maven, что-то настроил, но еще не все
В целом, удобно, что интегрировано, но еще сыро.
Можно ли указать в качестве зависимости другой проект, что бы он тоже подтянулся для сборки?
И можно ли шарить артефакты между проектами?
Такой вопрос, стокнулся с казалось бы тривиальной задачей в Jenkins — необходимо запускать job при попадании нового тега (с определенным именем, например build_[0-9]{6,10}). Казалось бы все должно быть очень просто, а на деле оказалось что нет. Например у нас есть следующая история
550313e -> 22ce31f -> e31e663 -> e4c4bf6 (head)
tag2 tag3 tag4 tag1Так вот в Jenkins cборка будет запущена только для head, для остальных 3х тегов она будет игнорироваться. Можно ли в gitlab ci обеспечить сборку в любом "направлении", чтобы при командах
$ git tag build_000001 e4c4bf6
$ git tag build_000002 550313e
$ git tag build_000003 22ce31f
$ git tag build_000004 e31e663я получил в итоге 4 билда?
docs.gitlab.com/runner/install
+ в карму, отличная статья для новичков. Понятно и довольно много информации в сжатом виде
Введение в GitLab CI