А
с cache все ок
Size: a a a
2020 February 12
AG
Алексей
в джобе docker вот так
А где ты его качаешь?
YD
А где ты его качаешь?
походу локальный кеш
А
артефакт?
YD
какой ранер?
А
docker executor
DV
Алексей
compile:
image: node:10
stage: build
before_script:
- npm install
- npm -v
script:
- npm run build
artifacts:
expire_in: 30 min
paths:
- build
#cache:
#paths:
#- build
docker:
image: docker:19.03
services:
- docker:19.03-dind
stage: build
before_script:
- mkdir -p images
script:
- docker build -t xxxx:yyyy ./build
image: node:10
stage: build
before_script:
- npm install
- npm -v
script:
- npm run build
artifacts:
expire_in: 30 min
paths:
- build
#cache:
#paths:
#- build
docker:
image: docker:19.03
services:
- docker:19.03-dind
stage: build
before_script:
- mkdir -p images
script:
- docker build -t xxxx:yyyy ./build
Так это джобы одной стадии. Вы же наверняка хотите сперва проект собрать, а потом образ. Разнесите на последовательные стадии, артефакты у вас уже описаны, они автоматом подтянутся на последующую стадию
DV
Кстати, для лучшей воспроизводимости сборок юзайте
npm ci вместо npm i, но надо не забывать package-lock.json коммитить в репАК
ru_gitlab! Я столкнулся с проблемой: во вкладке jobs сложно отличать какая job на каком stage запустилась
наверно все видели что это выглядит обычно так:
Можно ли динамически задавать stages или job_names, в виде параметров, прилетающих извне(?) и как это сделать?
Псевдокод как я примерно ожидаю это видеть:
наверно все видели что это выглядит обычно так:
stage | nameЧтобы разделить на env1 и env2 приходится копипастить(пусть и с наследованием), в yml, тогда получается
_______|______
build | build
test | test
test | test
build | build_env1Я перепробовал довольно много вариантов, и пришёл к копипасте с переиспользованием общих частей, но мне всё интересно, решал ли кто следующие вопросы:
test | test_env1
teat | test_env2
Можно ли динамически задавать stages или job_names, в виде параметров, прилетающих извне(?) и как это сделать?
Псевдокод как я примерно ожидаю это видеть:
variables:
VAR1: XX
VAR2: XXX
stages:
- $VAR1
- $VAR2
job_${VAR1}:
stage: $VAR1
DV
ru_gitlab! Я столкнулся с проблемой: во вкладке jobs сложно отличать какая job на каком stage запустилась
наверно все видели что это выглядит обычно так:
Можно ли динамически задавать stages или job_names, в виде параметров, прилетающих извне(?) и как это сделать?
Псевдокод как я примерно ожидаю это видеть:
наверно все видели что это выглядит обычно так:
stage | nameЧтобы разделить на env1 и env2 приходится копипастить(пусть и с наследованием), в yml, тогда получается
_______|______
build | build
test | test
test | test
build | build_env1Я перепробовал довольно много вариантов, и пришёл к копипасте с переиспользованием общих частей, но мне всё интересно, решал ли кто следующие вопросы:
test | test_env1
teat | test_env2
Можно ли динамически задавать stages или job_names, в виде параметров, прилетающих извне(?) и как это сделать?
Псевдокод как я примерно ожидаю это видеть:
variables:
VAR1: XX
VAR2: XXX
stages:
- $VAR1
- $VAR2
job_${VAR1}:
stage: $VAR1
Теоретически - можно юзать
include:remote и свой веб-сервер, который будет отдавать манифесты. Практически - хз, насколько это удобно. Ну и @kvaps пилил статью про jsonnet, это не совсем динамично, но, видимо, более компактно https://t.me/ru_gitlab/56339А
Так это джобы одной стадии. Вы же наверняка хотите сперва проект собрать, а потом образ. Разнесите на последовательные стадии, артефакты у вас уже описаны, они автоматом подтянутся на последующую стадию
Дмитрий, логика ясна. Но почему тогда на одной стадии они не подтягиваются автоматически?
DV
Видимо, все-таки не ясна. Все джобы одной стадии запускаются параллельно, как вы хотите их упорядочить совершенно непонятно. Ничего не мешает джобе
docker запуститься раньше джобы compile. Стадия подразумевает, что все джобы, относящиеся к ней, независимы друг от друга. Зависимости возникают только между стадиями. Соответственно и артефакты передаются между стадиями. Подробное описания передачи артефактов между стадиями в доках я не нарыл, но вот тут например черным по белому написао https://docs.gitlab.com/ee/ci/yaml/#dependenciesА
Спасибо, сейчас понятно, просто у меня при всех прогонах эти джобы проходили последовательно
Vs
господа и дамы подскажите пожалуйста, как в пайпллайне запретить retry ? что бы он прогнался и повторно уже нини его запустить
K
господа и дамы подскажите пожалуйста, как в пайпллайне запретить retry ? что бы он прогнался и повторно уже нини его запустить
Есть вот такая ишью, вроде как раз про этот случай
https://gitlab.com/gitlab-org/gitlab/issues/3657
https://gitlab.com/gitlab-org/gitlab/issues/3657
K
господа и дамы подскажите пожалуйста, как в пайпллайне запретить retry ? что бы он прогнался и повторно уже нини его запустить
Пока вижу 2 костыльных способа:
- Класть что-то в кеш/создавать артефакт по выполнении, а при запуске проверять наличие соотв. флага для этого коммита/тега/бранчи. Но оно сбросится при сбросе кеша/истечении TTL артефакта.
- Ходить первым шагом в API по
Надеюсь, можно как-то проще.
- Класть что-то в кеш/создавать артефакт по выполнении, а при запуске проверять наличие соотв. флага для этого коммита/тега/бранчи. Но оно сбросится при сбросе кеша/истечении TTL артефакта.
- Ходить первым шагом в API по
/projects/:id/pipelines и искать там, были ли запуски для этого коммита/тега/бранчи. Если были - фейлиться.Надеюсь, можно как-то проще.
Vs
Есть вот такая ишью, вроде как раз про этот случай
https://gitlab.com/gitlab-org/gitlab/issues/3657
https://gitlab.com/gitlab-org/gitlab/issues/3657
спасибо большое почитаю
Vs
Пока вижу 2 костыльных способа:
- Класть что-то в кеш/создавать артефакт по выполнении, а при запуске проверять наличие соотв. флага для этого коммита/тега/бранчи. Но оно сбросится при сбросе кеша/истечении TTL артефакта.
- Ходить первым шагом в API по
Надеюсь, можно как-то проще.
- Класть что-то в кеш/создавать артефакт по выполнении, а при запуске проверять наличие соотв. флага для этого коммита/тега/бранчи. Но оно сбросится при сбросе кеша/истечении TTL артефакта.
- Ходить первым шагом в API по
/projects/:id/pipelines и искать там, были ли запуски для этого коммита/тега/бранчи. Если были - фейлиться.Надеюсь, можно как-то проще.
ну у меня была идея что мол создавать артефакт и проверять его наличие.. если есть фейлится... но просто думал мож есть более стандартные пути...
АК
Теоретически - можно юзать
include:remote и свой веб-сервер, который будет отдавать манифесты. Практически - хз, насколько это удобно. Ну и @kvaps пилил статью про jsonnet, это не совсем динамично, но, видимо, более компактно https://t.me/ru_gitlab/56339Звучит непонятно и кажется неудобно для использования.