Использование артефактов позволяет job:
1. Подготовить данные
2. Заархивировать их
3. Передать в другой job
Особенности артефактов:
1. Не используется, если явно не определён в job
2. Доступен только в пределах указанной job
3. Хранится в GitLab
4. Можно указать время жизни, по умолчанию — 30 дней
Пример 1
job1, и job2 сохраняют файлы task1.txt и task2.txt как артефакты
job2:
запускается в stage2, который запускается после stage1
загрузит файлы task1.txt и task2.txt как артефакты job1 и позже переопределит их
job3:
запустится в stage3
загрузит артефакты со всех предыдущих этапов
но увидит только последнюю версию файлов task1.txt и task3.txt, написанных job2
Вывод:
Downloading artifacts
00:01
Downloading artifacts for job1 ()...
Downloading artifacts from coordinator... ok
Downloading artifacts for job2 ()...
Downloading artifacts from coordinator... ok
Executing "step_script" stage of the job script
00:00
Using docker image ...
$ cat task1.txt
job2 - executing task1
$ cat task2.txt
job2 - executing task2
Пример 2 dependencies добавьте явную зависимость job3 от job1
Хотя job3 не зависит от job2, он по-прежнему выполняется после job2
Использование ключевого слова dependencies не изменяет порядок выполнения заданий
Все задания выполняются последовательно в соответствии с порядком этапов
Однако job3 использует ключевое слово dependencies, которое загружает артефакты из job1
job3 не загрузит артефакты из job2, т.к. мы указали явную зависимость только от job1
Вывод:
Downloading artifacts
00:01
Downloading artifacts for job1 ()...
Downloading artifacts from coordinator... ok
Executing "step_script" stage of the job script
00:01
Using docker image ...
$ cat task1.txt
job1 - executing task1
$ cat task2.txt
job1 - executing task2
Cleaning up project directory and file based variables
00:00
Job succeeded
Caches
Способ сохранить данные между job, этапами пайплайна или разными пайплайнами
Полезен для зависимостей тип - node_modules/, .m2/, venv/ и т.д.
Cache:
1. Не используется, если явно не указать в job или глобально с помощью cache
2. Доступен для всех job, если используется глобально
3. Хранится на GitLab Runner
Для базовой настройки cache в .gitlab-ci.yml требуются три ключевых элемента
paths — указывает директории или файлы, которые необходимо кэшировать
В этом случае кэшируется директория node_modules, где npm сохраняет зависимости проекта
key — определяет ключ кэша, который используется для ассоциации кэша с конкретными задачами и условиями
В примере ключ задаётся как ${CI_COMMIT_REF_SLUG}, что означает использование уникального идентификатора ветки в качестве ключа
Это позволяет каждой ветке иметь свой собственный кэш, предотвращая конфликты
Установить общий локальный кэш для всех заданий на одном раннере .gitlab-ci.yml:
default:
cache:
path:
- some_dir/path/to/folder/*.txt
- some_dir/path/to/file
Привязать общий локальный кэш для всех заданий на одном раннере к конкретной ветви:
default:
cache:
key: $CI_COMMIT_REF_NAME
path:
- relative/path/to/folder/*.ext
- relative/path/to/another_folder/
- relative/path/to/file
Основа вашей стратегии кэширования
Ключ кэша определяет, когда GitLab создает новый кэш, а когда повторно использует существующий
Неправильный выбор ключа является наиболее распространенной ошибкой кэширования
Это приводит:
к сбоям в работе кэша (ненужная перестройка)
к загрязнению кэша (использование устаревших зависимостей)
Вот наиболее эффективные ключевые стратегии
# Стратегия 1: Кэш для конкретной ветки (подходит для большинства проектов)
cache:
key: "${CI_COMMIT_REF_SLUG}"
paths:
- node_modules/
# Стратегия 2: Блокировка хэша файла (лучше всего подходит для кэширования зависимостей)
cache:
key:
files:
- test.txt
paths:
- node_modules/
Подход к хэшированию файла блокировки (стратегия 2) особенно эффективен
Создает новый кэш только при фактическом изменении зависимостей
Если test.txt не изменился, то будет повторно использован существующий кэш даже в разных ветвях
Политики кэширования: Контролируют загрузку и выгрузочное поведение
GitLab предлагает три политики кэширования, которые контролируют загрузку и выгружаемый кэш:
pull-push (по умолчанию): Загружает кэш в начале задания, загружает в конце
pull: загружает только кэш, никогда не обновляет его (идеально для заданий с большим объемом чтений)
push: загружает только кэш, не загружает (используется для заданий по созданию кэша)
Используйте разные политики для разных типов заданий, оптимизируя производительность конвейера
# Эти задания считываются только из кэша
test_unit:
stage: test
script:
- npm run test:unit
cache:
key:
files:
- package-lock.json
paths:
- node_modules/
policy: pull
В этом примере определяется глобальный кэш для node_modules/
Кэш используется как при сборке, так и при тестировании в конвейере
Область действия кэша определяется именем ветви с использованием предопределенной переменной ${CI_COMMIT_REF_SLUG}
stages:
- build
- test
cache:
key: "npm-${CI_COMMIT_REF_SLUG}" # Расширяет область действия кэша до имени ветви
paths:
- node_modules/
build-job:
stage: build
script:
- npm install # Загружает и кэширует модули узлов
- npm run build
# Ключевое слово "cache" здесь неявно использует глобальные настройки кэша
test-job:
stage: test
script:
- npm install # Повторно использует кэш 'node_modules/' из задания build-job
- npm run test
Простой пример кэширования на Python
В этом примере определяется глобальный кэш для всех заданий в конвейере
В кэше хранится кэш pip и виртуальная среда для каждой ветви
variables:
# Измените каталог кэша pip на находящийся внутри каталога проекта
# , чтобы мы могли кэшировать его как локальный артефакт.
PIP_CACHE_DIR: "$CI_PROJECT_DIR/.cache/pip"
VENV_PATH: "$CI_PROJECT_DIR/venv"
image: python:3.10
cache:
# Расширяет область действия кэша до имени ветви
key: ${CI_COMMIT_REF_SLUG}
paths:
- .cache/pip
- venv/
before_script:
- python --version
# Создание и активация виртуальной среды
- pip install virtualenv
- virtualenv $VENV_PATH
- source $VENV_PATH/bin/activate
# Установить зависимости из файла requirements.txt
- pip install -r requirements.txt
stages:
- build
- test
build_job:
stage: build
script:
- echo "Build phase (dependencies are already installed)"
# Add your build commands here
test_job:
stage: test
script:
- echo "Test phase (dependencies are already installed)"
# Run tests using the cached venv
- pytest
Комментарии пользователей
Эту новость ещё не комментировалиНаписать комментарий
Анонимам нельзя оставоять комментарии, зарегистрируйтесь!
Код обмена баннерами