Comments 13
Я думаю, что стоит добавить, что стОит перекатываться с "only/except refs" на "rules". У последних сильно более гибкий синтаксис. И если я правильно понял — в дальнейшем от only/except сами гитлабовцы откажутся
+2
Очень не хватает управления кэшированием. В том смысле, что сейчас кэш — это zip с ненастраиваемой степень сжатия. Минуса два:
— Если в проекте много файлов, жать будет долго. На нашем проекте мне приходится пересобирать runner с единственной правкой — метод сжатия Store (без сжатия).
— Zip не хранит дробную часть timestamp, из-за чего ломается кэширование сборки у таких компиляторов как например sbt для scala.
— Если в проекте много файлов, жать будет долго. На нашем проекте мне приходится пересобирать runner с единственной правкой — метод сжатия Store (без сжатия).
— Zip не хранит дробную часть timestamp, из-за чего ломается кэширование сборки у таких компиляторов как например sbt для scala.
+2
.gitlab-ci.yaml разрастается уже до таких глубин, что ему начинает не хватать UI-редактора и средств отладки. Со временем понимать почему что-то там запустилось или не запустилось будет всё сложнее.
+4
Я бы ещё добавил недавно появившуюся возможность давать доступ в группу проектов другой группе (например, "Developers").
+1
А есть возможность простр не загружать артефакты для некоторых джоб? Вчера нашёл только через needs, но тогда не ждёт окончания стейджа всегр
+1
Может здесь кто нибудь подскажет. Каждую ночь по schedule запускается coverage job и бейдж работает в ридми, показывает процент покритии. Но если запускаем какой нибудь другой job после этого, то процент покритии на бейдже исчезает. Мы не можем запускать coverage job на каждый push, это долго. Как быть?
+1
extends, include чудесно!
0
С rules есть один баг. По крайней мере при вот таком конфиге:
Текущий стейдж помечается не зелененьким, как выполненый, а «шестеренкой», как «manual job». Вся логика работает, просто пока не заглянешь внутрь стейджа, непонятно, выполнилась задача или нет.
rules:
- if: '$CI_COMMIT_REF_NAME == "master"'
when: delayed
start_in: 60 seconds
- when: manual
Текущий стейдж помечается не зелененьким, как выполненый, а «шестеренкой», как «manual job». Вся логика работает, просто пока не заглянешь внутрь стейджа, непонятно, выполнилась задача или нет.
+2
UFO just landed and posted this here
Подскажите, а как вы делаете when без впереди тире? я понимаю смысл, но gitlab так не дает и ругается на ошибку
rules:
- if: '$VARIABLES_START == "error"'
when: never
- if: '$CI_PIPELINE_SOURCE != "schedule"'
when: never
Так ругается и всё тут
0
Sign up to leave a comment.
GitLab CI: 6 фич из последних релизов, которых мы так ждали