cache:
paths:
- .m2/repository/
key: "project-a-${CI_COMMIT_REF_SLUG}"
Я так полагал, что оно распакует или примаунтит директорию, которая осталась от предыдущей job (или ранее запущеного того же самого pipeline) в директорию рабочую, в которой runner начинает свои манипуляции с репозиторием, для теста смотрю в script или before_script
ls -al .m2/repository/
ls -al ${CI_PROJECT_DIR}/.m2/repository
Говорит нет такой директории
Возникает вопрос. Может я сначала должен её создать, если её нет. Потом уже сам Maven при сборке пакетов насобирает и насоздаёт директорию, и второй раз будет чего распаковывать?
MAVEN_OPTS: "-Dmaven.repo.local=${CI_PROJECT_DIR}/.m2/repository"
Restoring cache
00:01
Checking cache for project-a-main...
No URL provided, cache will not be downloaded from shared cache server. Instead a local version of cache will be extracted.
Successfully extracted cache
Executing "step_script" stage of the job script
00:00
$ cd .m2/repository/
/scripts-119111-5840135/step_script: line 159: cd: .m2/repository/: No such file or directory
Почему это все не заменить одним заданием в Docker. Нужно только написать multi-stage Dockerfile. В докере гораздо проще что-то в одном месте собирать, потом передавать в другое место.
Можно конечно и так, насобирать всего и подсунуть свой образ. Но очень хочется, сейчас понять про кеш.
Тут вопрос в том, что в прошлом запуске пайплайна или в прошлой джобе этого же пайплайна эта директория должна была быть, чтобы она могла быть закеширована и только после этого она будет доступна. Вот тут есть описание как оно работает. https://docs.gitlab.com/ee/ci/caching/#how-archiving-and-extracting-works
Плюс у вас еще зависимость от имени бренча, соответственно, бренч должен быть один и тот же
Да один и тот же. Пологаю не было директории, она и не кешировалась. Спасибо
Обсуждают сегодня