Softmart corporate blog
IT systems testing
Git
Web services testing
Build automation
Comments 17
+1
compile:
stage: compile
script: cat file1.txt file2.txt > compiled.txt
artifacts:
paths:
— compiled.txt


А для чего указывать артефакт в задаче compile? Файл compiled.txt понятно, он нам будет нужен в следующих задачах. А зачем его описывать как артефакт?

+1

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

0
А что значит «для передачи файлов между stages»?

В следующих стадиях/задачах используется имя файла compiled.txt. Я так понимаю, это тот самый файл compiled.txt, который создался в задаче compile. Вот просто создался он в задаче compile и лежит себе, а в следующих задачах мы к нему обращаемся.

Без указания артефакта мы не сможем обратиться в нему в следующей задаче? Он будет удален по окончанию задачи compile? А указание артефакта это типа «поставить галочку, что этот файл удалять не надо»?
0
Разные задачи могут выполняться на разных раннерах, поэтому нужно передавать артефакты.
0
А вот в обсуждаемой статье — используется один раннер? В одном раннере сработает обращение к файлу без указания артефакта?
0
В статье не указано ничего о том что только один раннер, каждая задача выполняется независимо, есть раннер которые его выполняет. раннеры бывают разные, можно использовать те что бесплатно предоставлены gitlab там их сейчас два, физически они в DigitalOcean
раннеры можно и свои запустить, linux, macos или windows, раннер этот может и не использовать докер вообще, а только локально выполнять команды
поэтому и нужна возможность перетягивать файлы между задачами, но при этом весь репозиторий клонируется на всех задачах
0

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

0
Так это же просто файл в репозитории. Он одинаковый во всех ветках. Как он может быть разным? Если только Вы специально измените его в конкретной ветке, но зачем это делать, если Вам как-раз надо, чтобы он был одинаковым.
0

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

0
Ну да, как и любой другой файл. Вы в любой случае все ветки синхронизируете с мастером, заодно и новый файл прилетит в ветку.
+1

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

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

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

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

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

0

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

0
Ничего из описанного не работает:( Вообще не запускается, появляется значок «pending» и всё.

Я так понимаю, нужен некий раннер. Какой минимум нужно сделать, чтобы запустить хотя бы самый простейший тест?
Only those users with full accounts are able to leave comments., please.