Введение в GitLab CI

[nem]

artifacts используется и для передачи файлов между stages, и для попадания в downloadable artifacts. Возможно это поменятся, но пока так.

[abogoyavlensky]

Разные задачи могут выполняться на разных раннерах, поэтому нужно передавать артефакты.

[DAiMor]

В статье не указано ничего о том что только один раннер, каждая задача выполняется независимо, есть раннер которые его выполняет. раннеры бывают разные, можно использовать те что бесплатно предоставлены gitlab там их сейчас два, физически они в DigitalOcean
раннеры можно и свои запустить, linux, macos или windows, раннер этот может и не использовать докер вообще, а только локально выполнять команды
поэтому и нужна возможность перетягивать файлы между задачами, но при этом весь репозиторий клонируется на всех задачах

[iliacmd]

Сюда напишу по ближе к началу :)

Из статьи не очевидно, что артифакт передается через все стадии, т.е. если артифакт получен в compile, то он доступен и в test и в package. (версия Gitlab 14.7.0)

Определяет команды, которые выполняются перед всеми заданиями

before_script выполняется перед script задания, а не всех заданий, по крайней мере размещение before_script за пределами конкретной задачи не рассматривается в статье.

Задачи могут выполняться последовательно, параллельно, либо вы можете задать свой собственный порядок выполнения, создав конвейер.

Не совсем понятно, есть какой-то третий вариант с конвеером? Если я правильно понял, то конвеер получается благодаря этапам (stages), через которые мы можем определять порядок выполнения задач, хотя задачи внутри этапа вроде как выполняются параллельно, и тогда не понятно а можно ли внутри этапа задать последовательность выполнения или нужно вводить новый этап.

В целом статья понравилась, соответствует заголовку.

[past]

Подскажите, можно ли иметь единый .gitlab-ci.yml для всех веток?

[past]

На стадии его написания многократно приходится синхронизировать его между ветками.

[past]

И еще вопрос, можно как-то динамически формировать имя артефакта?
У меня после сборки получается файл package-${version}-${release}.el7.centos.${arch}.rpm при чем переменные вычисляются в процессе сборки.

[DAiMor]

Можно самому упаковать папку и задать имя на основе переменных, есть ряд переменных которые gitlab сам формирует
если переменные вычисляются, то они могут попасть в переменные окружения и использоваться для формирования имени
нужно учитывать что блок scripts, это команды операционной системы и выбранного шелла, да ведь раннер может быть и на винде и команды могут быть powershell

[utoplenick]

Было бы неплохо рассказать и о раннерах, раз уж зашла речь про gitlab-ci, потому как в данном примере совсем непонятно зачем вообще нужен докер чтобы грепнуть файл? Понятно что пример простой, а статья — переводю

[IgorStepin]

Функционала меньше, чем в Jenkins (это нормально, нужно учитывать):
— нет постоянных ссылок на скачивание последних артефактов (latest, а не номер билда; удобно для скриптов бутстрапа, например)
— вроде бы в последних версиях ручной запуск появился, но нет параметризированного запуска (может и не нужно, можно тот же список серверов забить в файл отдельными ручными работами, но нужно учитывать при проектировании)
— нет работ не привязанных к ветке/репозитарию (из-за этого придется для некоторых вещей сохранить Jenkins)
— нотификации (типа интеграции со слаком) идут вне файла настройки ci

Текущие минусы:
— долго промучился, но команды сборки докера в докере не заработали (ни docker in docker, который не предназначен для систем CI и постоянно в документации Gitlab CI упоминается; ни пробрасывание сокета докера), использую отдельный shell runner для этого.
— кеширует только после успешного завершения работы (например, пока настраиваешь работу каждый раз качает плагины maven)
— медленно (пофайлово?) сохраняет кеш
— нет способа через UI сбросить кеш и посмотреть какие кеши есть. все-таки кеши время от времени приходится сбрасывать
— по ощущениям собирает медленней Jenkins, относительно долго (секунд 15) запускается любая докер-работа с одной командой echo
— нет готового рецепта для Java/Maven, что-то настроил, но еще не все

В целом, удобно, что интегрировано, но еще сыро.

[fshp]

Можно ли указать в качестве зависимости другой проект, что бы он тоже подтянулся для сборки?
И можно ли шарить артефакты между проектами?

[ALexhha]

Такой вопрос, стокнулся с казалось бы тривиальной задачей в 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 билда?

[aniserg]

Установить gitlab-runner и загеристировать его в gitlab
docs.gitlab.com/runner/install

[sergey_privacy]

+ в карму, отличная статья для новичков. Понятно и довольно много информации в сжатом виде