L
Версионирование по коммитам — у имеджей. Кэша — по веткам 🧠
Size: a a a
2021 May 18
O
а, ну ок, теперь более-менее понятно:)
L
Плюс там можно использовать несколько
cache-from, и мы там подтягиваем кэш из мастера для первого билда в веткеO
А как рефреш кэша работает? Или есть эмпирические правила, которые не позволяют использовать невалидный кэш в рамках ветки?
O
Или он при каждой сборке эффективно рефрешится?
L
Да, там buildx сам решает, какие слои невалидные больше
O
Эм, погоди. Вот у тебя в кэшах лежат дэпы. У тебя изменился код и ему нужна новая версия депенденси. Изменение в рамках бранча произошло. Как эта новая версия дэпа в кэш попадет?
L
Ну там используются механизмы слоев докера. Один из слоев у нас — копирование lock файла. Если он поменяется, этот слой инвалидируется, и все после него заново выполнятся
O
А, окей, теперь понятно. То есть вы валидируете его фактически каждый билд.
L
+
L
Кстати сегодня обновили гитлаб и он стал нормально отображать kaniko кэши с reproducible
IV
как здорово circleci придумал - если мерджишь в main ветку где последний коммит был [skip ci] fix typo, то circleci просто не билдит main 🤦
L
🧠
IV
а как вы знаете возможности сделать force build там нет, есть Re-Run который не запускает задачу потому что [skip ci] 😄
A
продумано
AP
jobs:
test:
runs-on: ubuntu-latest
if: "!contains(github.event.head_commit.message, '[ci skip]')"
test:
runs-on: ubuntu-latest
if: "!contains(github.event.head_commit.message, '[ci skip]')"
IV
skip ci работает в коробке circleci, не нужно писать доп фильтры, но имхо, при мердже они не должны его учитывать
VI
вангую где-то глубоко они это учитывают при мердже в master, но не в main
IV
проверил. не работает для master