Gitlab runner очистить кэш
Если вы используете Git и GitLab для хранения кода, то можете упростить и автоматизировать разворачивание вашего кода на сервере сразу же, при появлении новых изменений в GitLab репозитории. Этот процесс называется CI/CD (Continuous Integration, Continuous Delivery или Непрерывная интеграция и доставка). С помощью этой технологии вы можете выполнять тесты, собирать проект, а затем помещать результат сборки или исходники в нужное место.
В этой небольшой статье будет рассмотрена настройка GitLab CI CD для небольшого проекта на PHP без сборки и тестов, а только с копированием исходников в директорию веб-сервера на сервере проекта.
Настройка GitLab CI/CD
1. Установка GitLab Runner
Для того чтобы у GitLab был доступ к серверу, на этот сервер необходимо установить службу gitlab-runner. Именно эта программа будет забирать новые исходники с GitLab, выполнять с ними нужные действия и разворачивать на сервере. Установить её в Ubuntu можно из официальных репозиториев. Сначала добавьте репозиторий в систему:
curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash
Обратите внимание, что поддерживаются Ubuntu 16.04, 18.04 и 20.04, если у вас другая версия, после установки репозитория вам надо будет изменить его на версию для ближайшего поддерживаемого дистрибутива. После этого можно установить пакет:
sudo apt install gitlab-runner
Так выполняется установка GitLab runner Ubuntu. В CentOS и других Red Hat дистрибутивах процедура установки похожая. Сначала добавьте репозиторий:
curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh" | sudo bash
Затем установите пакет:
sudo yum install gitlab-runner
Возможно, в будущем процедура или ссылки на пакеты изменятся. Смотрите официальную документацию.
После установки запустите сервис с помощью systemd и добавьте его в автозагрузку:
sudo systemctl enable --now gitlab-runner
Откройте репозиторий на GitLab, для которого вы хотите настроить CI/CD, затем кликните по шестеренке (пункт Settings) в меню, а потом выберите CI/CD:
Возле пункта Runners нажмите кнопку Expand:
Общие раннеры от GitLab можно отключить для того чтобы они вам не мешали и не забирали задачи у вашего раннера. Для этого под надписью Enable shared runners for this project установите значение выключателя в положение выключено:
Необходимая вам информация находится в левой части окна, в разделе Specific runners. Тут вам надо узнать URL сервиса и токен авторизации, с которым вы будете регистрировать раннер:
Теперь возвращайтесь на сервер, на котором был установлен runner и выполните такую команду:
sudo gitlab-runner register
Программа спросит URL и токен, которые вы узнали на GitLab.
Затем надо ввести описание и теги для раннера. Теги будут использоваться в будущем для того чтобы отправлять этому раннеру задания. Далее останется только выбрать способ выполнения команд. Для того чтобы просто запускать командную оболочку можно выбрать shell.
Обратите внимание, что команду надо выполнять именно с sudo. Поскольку демон выполняется от имени пользователя root, то и авторизацию нужно выполнять от имени этого пользователя, иначе работать не будет, но и ошибок не выдаст.
Для того чтобы убедится, что всё настроено и работает нормально выполните такую команду:
sudo gitlab-runner verify
3. Настройка GitLab Runner
Кликните по значку карандаша (Edit) возле раннера и выставьте такие настройки:
- Active - должно быть включено, иначе раннер не сможет выполнять задания;
- Protected - должно быть включено, для того чтобы раннер брал задания из всех веток, а не только защищённых;
- Run untagged jobs - должно быть включено, позволяет раннеру брать задачи без тегов;
- Lock to current projects - если включено, этот раннер доступен только для этого проекта.
Все остальные опции можно не трогать.
После завершения настройки на забудьте нажать кнопку Save Changes. Дальше можно переходить к созданию файла .gitlab-ci.yml.
4. Создание gitlab-ci.yml
Именно в этом файле описываются все задачи, а также команды, которые gitlab-runner будет выполнять на сервере. Вы можете создать его вручную или же, если такого файла ещё нет, то на главной странице проекта нажмите кнопку Setup CI/CD:
После этого кликните по кнопке Create New CI/CD Pipeline:
Дальше перед вами откроется редактор файла .gitlab-ci.yml.
Как и следует из расширения - это файл в формате YAML, поэтому отступы перед значениями очень важны. Сразу же можете удалить отсюда все комментарии. Структура файла примерно такая:
Раздел stages описывает этапы разворачивания приложения и очередность их выполнения. Затем описываются задачи, которые будут выполняться в рамках каждого этапа. У задачи должен быть указан этап: stage и script со списком команд, которые будут выполняться на сервере. Во время разворачивания gitlab-runner автоматически создает на сервере (по умолчанию в домашней папке) директорию build, клонирует туда свежие исходники проекта и переходит в папку с исходниками. А дальше с помощью команд в секции script вы можете делать всё, что нужно с этими исходниками.
Для этого примера можно оставить только секцию deploy. Самый простой конфигурационный файл будет выглядеть вот так:
stages:
- deploy
deploy-job:
stage: deploy
script:
- echo "Deploying application. "
- echo "Application successfully deployed."
Сохраните этот файл. Для этого пролистайте вниз страницы и нажмите кнопку Commit Changes.
5. Проверка работы Pipeline
Если всё было сделано правильно, то ваш раннер получит эту задачу, склонирует исходники и выведет две строчки в терминал. Для того чтобы убедится что это всё произошло, в боковом меню выберите значок ракеты (CI/CD) а затем Pipelines:
Здесь отображаются все задачи CI/CD. В данном случае у вас должна быть одна задача.
Если всё прошло успешно перед ней будет зеленая кнопка Passed. Для того чтобы посмотреть лог выполнения задачи, кликните по этой кнопке, а затем выберите непосредственно задачу из списка:
В результате откроется лог выполнения раннера для этой задачи:
Поскольку внизу зелёным написано Job succeeded, значит задача выполнилась успешно. В самом верху лога вы можете видеть какой раннер использовался для выполнения, убедитесь, что это именно ваш раннер, а не один из стандартных.
6. Разворачивание исходников
Программа уже скачивает исходники на сервер, но дальше вы можете сделать с ними всё что хотите. Настраивать раннер загружать исходники прямо в папку веб-сервера не стоит, программа для этого не предназначена. Для копирования исходников лучше использовать rsync. Эта утилита позволяет копировать только изменившиеся файлы. Например, для копирования файлов из репозитория в /var/www/project необходимо добавить такую команду в секцию script:
rsync -av --no-perms --no-owner --no-group --exclude ".git*" $CI_PROJECT_DIR/ /var/www/project
Для редактирования файла .gitlab-ci.yml можете воспользоваться пунктом меню CI/CD -> Editor или найти и отредактировать этот файл в списке файлов. Папка, в которую вы собираетесь разврачивать проект должна существовать на сервере и у пользователя gitlab-runner должны быть права на запись в неё:
sudo mkdir -p /var/www/project
sudo chown gitlab-runner:gitlab-runner /var/www/project
Если всё было сделано верно на этот раз, то файлы появятся в папке:
Аналогичным образом вы можете добавлять другие команды, которые необходимо выполнить с исходниками на сервере. Можно даже загружать их на другие сервера с помощью того же rsync. Вообще говоря, локально можно было бы и обойтись без этой утилиты и воспользоваться cp. Но rsync позволяет именно синхронизировать изменения, что очень удобно.
Выводы
Теперь вы знаете как выполняется настройка GitLab CI CD, а также GitLab-runner. Как видите, это довольно полезные инструменты. Теперь на сервере будут оказываться все новые коммиты и у вас больше не будет необходимости выгружать их туда вручную.
Нет похожих записей
Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна.
Из-за прекращения поддержи Bitbucket Setver пришлось переехать на GitLab.
В Bitbucket Server не было встроенного CI/CD, поэтому использовали Teamcity. Из-за проблемы интеграции Teamcity с GitLab, мы попробовали GitLab Pipline. И остались довольны.
Disclamer: У меня не так много опыта в CI/CD, так что статья скорее для новичков. Мы рассмотрим самый простой пример деплоя на несколько контуров с доставкой с помощью scp и запуском linux сервиса. Буду рад услышать конструктивную критику с предложениями по оптимизации скрипта сборки.
Коротко о Gitlab Pipline
Если говорить простыми словами: сборка делится на задачи. Какие-то задачи выполняются последовательно и передают результаты следующим задачам, какие-то задачи распаралеливаются: например можно одновременно деплоить на сервер и в nexus.
Не обязательно один раннер отвечает за все задачи в сборке. Если на проекте два раннера, то первую задачу может взять один ранер, после ее выполнения вторую задачу возьмет другой раннер.
Раннеры бывают разных типов. Мы рассмотрим executor docker. Для каждой задачи создается новый чистый контейнер. Но между контейнерами можно передавать промежуточные результаты — это называется кэширование.
Кэширование и его особенности
Механизм кэширования разрабатывал какой-то одаренный человек. Поэтому сразу разобраться, как оно работает, будет не просто. В отдельной статье можно прочитать о кэшировании подробнее.
Каждый раннер хранит кэш в папке /cache . Для каждого проекта в этой папке создается еще папка. Сам кэш хранится в виде zip архива.
Можно определить только один набор папок для кэша. Также только для всего набора можно выбрать политику кэширования. Например если вы уверены, что задача не изменит кэш, то можно его не загружать. Но нельзя запретить загружать например две папки из четырех.
Нет возможности установить глобальный кэш и добавить к нему дополнительные папки для конкретных задач.
Так же стоит знать, что кэш не удаляется после окончания сборки. При следующей такой же сборке старый кэш будет доступен.
Эти особенности усложняют создание инструкций для CI CD.
Артефакты
Помимо кэша между сборками можно передавать артефакты.
Артефакт — это файлы, которые считаются законченным продуктом сборки. Например .jar файлы приложения.
В отличие от кэша, артефакт передается между раннерами. Из-за этого многие злоупотребляют использованием артефактов там, где стоит использовать кэш.
Следуйте следующим правилам:
- Если текущее задание может выполняться самостоятельно, но в присутствии контента работа будет идти быстрее, используйте кэш.
- Если текущее задание зависит от результатов предыдущего, то есть не может выполняться само по себе, используйте артефакты и зависимости.
Установка Gitlab Runner
Перед установкой ранера создадим папку с конфигурацией, чтобы не приходилось для изменений лезть в контейнер.
Само создание ранера выполняется в одну команду. Можно создать сколько угодно ранеров.
Мало создать раннер, теперь его нужно зарегистрировать в GitLab. Зарегистрировать можно на уровне всего GitLab, тогда сборки будут выполняться для любого проекта; на уровне группы — выполнятся только для группы, и на уровне проекта.
Заходим в контейнер.
Отвечаем на вопросы:
- Адрес вашего gitlab.
- Токен авторизации. Посмотреть его можно в настройках гурппы/проекта в разделе CI/CD Runners.
- Название раннера.
- Теги ранера, можно пропустить нажав Enter.
- Исполнитель сборки. Вводим docker.
- Образ, который будет использоваться по умолчанию, если не установлен другой.
После этого в настройках проекта можно посмотреть доступные раннеры.
После регистрации, в папке /home/user/runner_name появится файл с настройками конфигурации config.toml . Нам нужно добавить docker volume для кэширования промежуточных результатов.
Проблема кэширования
В начале статьи я рассказал о проблеме кеширования. Ее можно решить с помощью монтирования одного volume к разным раннерам. То есть во втором своем раннере так же укажите volumes = ["gitlab-runner-cache:/cache"] . Таким образом разные раннеры будут иметь единый кэш.
В итоге файл конфигурации выглядит так:
После изменения перезапускаем раннер.
Что хотим получить от CI CD?
У нас на проекте было 3 контура:
- dev-сервер, на него все попадает сразу после MR;
- пре-прод-сервер, на него все попадает перед попаданием на прод, там проходит полное регресс тестирование;
- прод-сервер, собственно сама прод среда.
Что нам было необходимо от нашего CI/CD:
- Запуск unit-тестов для всех MergeRequest
- При мерже в dev ветку повторный запуск тестов и автоматический деплой на dev-сервер.
- Автоматическая сборка, тестирвоание и деплой веток формата release/* на пре-прод-сервер.
- При мерже в master ничего не происходит. Релиз собирается при обнаружении тега формата release-* . Одновременно с деплоем на прод-сервер будет происходить загрузка в корпоративный nexus.
- Бонусом настроим уведомления о статусе деплоя в Telegram.
Настройка GitLab CI для Maven
Что делать если у вас Gradle? Загляните в оригинал статьи, там я рассказываю про настройку и для Gradle. Она не сильно отличается.
Создайте в корне проекта файл .gitlab-ci.yml .
Настройку буду объяснять блоками, в конце прикреплю единый файл.
Вы можете указать нужный образ, вместо дефолтного образа у раннера.
Устанавливаем место хранения папки .m2 через переменные среды variables . Это понадобится, когда будем настраивать кэширование.
Далее указываются этапы сборки. Они позволяют группировать задачи для одновременного выполнения.
- build — стадия сборки.
- test — стадия тестирования.
- package — стадия упаковки в jar.
- deploy — стадия деплоя на сервер.
- notify — стадия уведомления о провале.
Указываем непосредственно задачи для каждой стадии.
Сборка — Build
Раздел script выполняет linux команды.
Переменная GitLab CI/CD $MAVEN_SETTINGS необходима для передачи файла settings.xml , если вы используете нестандартные настройки, например корпоративные репозитории. Переменная создается в настройках CI/CD для группы/проекта. Тип переменной File.
Раздел only указывает для каких веток и тегов выполнять задачу. Чтобы не собирать каждую запушенную ветку устанавливаем: dev , merge_requests и ветки формата /release/* .
Раздел only не разделяет ветка это или тег. Поэтому мы указываем параметр except , который исключает теги. Из-за этого поведения за сборку на прод отвечают отдельные задачи. В противном случае, если бы кто-то создал тег формата release/* , то он бы запустил сборку.
Для защиты от случайного деплоя в прод джуном, рекомендую установить защиту на ветки dev , master , /release/* , а так же на теги release-* . Делается это в настройках проекта GitLab.
Раздел cache отвечает за кэширование. Чтобы каждый раз не выкачивать зависимости добавляем в кэш папку ./target и ./.m2 .
Запуск unit тестов — test
Создаем задачу для запука тестирования.
Упаковка — package
Следом добавляем задачу упаковки с выключенными тестами. Она уже выполняется только для веток dev и release/* . Упаковывать Merge Request смысла нет.
Обратите внимание на policy: pull и artifacts . В следующих задачах не нужны исходники и зависимости, так что policy: pull отключает кэширование. Для сохранения результатов сборки используем artifacts , который сохраняет .jar файлы и передает их следующим задачам.
Деплой — deploy
Теперь осталось задеплоить артефакт на dev-сервер с помощью ssh и scp.
Не забудьте создать переменные в GitLab CI CD:
- $DEV_USER — пользователь системы, от чьего имени будет происходить деплой.
- $DEV_HOST — ip адрес сервера.
- $DEV_APP_PATH — путь до папки приложения.
- $SSH_PRIVATE_KEY — приватный ключ.
Раздел before_script отвечает за выполнение настроек перед основным скриптом. Мы проверяем наличие ssh-agent, устанавливаем его при отсутствии. После чего добавляем приватный ключ, устанавливаем правильные права на папки.
В разделе script происходит деплой на сервер:
- Проверяем наличие старого jar и переименовываем его. $CI_PIPELINE_ID — это глобальный номер сборки Pipeline.
- Копируем новый jar на сервер.
- Останавливаем и запускаем службу, отвечающую за приложение.
- Отправляем уведомление об успехе в телеграм. Об этом ниже.
На пре-прод делаем по аналогии, только меняем переменные на $PRE_PROD_* .
Настройка деплоя на прод
Для прод-деплоя можно объединить сборку, тестирование и упаковку в одну задачу.
Мы защищаемся от срабатывания на ветки формата release-* , нам нужно срабатывание только по тегу.
Деплой аналогичен пре-проду, изменяется только only и переменные.
Дополнительно появляется задача с отправкой артефакта в корпоративный nexus. Деплой на сервер и в нексус работает параллельно.
Бонус: уведомления о деплое в Telegram
Полезная фишка для уведомления менеджеров. После сборки в телеграм отправляется статус сборки, название проекта и ветка сборки.
В задачах деплоя последней командой пропишите:
Сам файл необходимо добавить в корень проекта, рядом с файлом .gitlab-ci.yml .
Скрипт отправляет запрос к API Telegram, через curl. Параметром скрипта передается emoji статуса билда.
Не забудьте добавить новые параметры в CI/CD:
Необходимо создать задачи для уведомления о падении сборки.
По сложившейся традиции у нас отдельная задача для прод-среды. Благодаря параметру when: on_failure задача отрабатывает только, когда одна из предыдущих завершилась неудачно.
Удобно, что теперь и код и сборка находятся в одном месте. Несмотря на недостатки GitLab CI, пользоваться им в целом удобно.
Привет! Меня зовут Антон Якутович. Занимаюсь тестированием более восьми лет. Специализируюсь на тестировании веб-сервисов, в основном бэкенда. Организую митапы по тестированию и автоматизации Ministry of Testing Abu Dhabi. Помимо тестирования, занимаюсь поддержкой
В этой статье хочу на примерах объяснить разницу между кешем и артефактами. И показать, как оптимально настроить пайплайн для Node.js-приложения.
Можно вечно смотреть на три вещи: как горит огонь, льётся вода и как билд проходит пайплайн после очередного коммита. Чтобы ожидание не было утомительным, лучше позаботиться о настройке CI сразу. Кеш и артефакты помогают сократить время прогона пайплайна.
Многие путают эти абстракции и не всегда используют по назначению. У GitLab богатая документация, но примеры использования кеша для Node.js-проекта и пример шаблона пайплайна для Node.js противоречат друг другу.
Pipeline внутри GitLab представляет собой набор стейджей (стадий). В каждом стейдже может быть одна или несколько джоб. Каждая джоба может запускаться на отдельном раннере. GitLab-runner — это агент, который занимается запуском джоб. Для простоты считаем, что все раннеры запускаются в докере.
Когда запускаем пайплайн, каждая джоба будет выполняться на раннере со свободными ресурсами. Заранее неизвестно, где физически расположен этот раннер. Система распределенная.
Каждая джоба стартует с «чистого листа» и не знает результаты предыдущей. Если не использовать кеш и артефакты, при установке зависимостей проекта придётся сходить в интернет или локальный registry и скачать необходимые пакеты.
Что такое кеш?
Набор файлов, которые могут скачиваться джобой перед запуском и выгружаться после исполнения. Кеш хранится там же, где установлен GitLab Runner. Если настроен распределённый кеш, в качестве хранилища выступает S3.
Предположим, запустили пайплайн первый раз с локальным кешем. Для первой джобы Build кеш не будет найден. Джоба выполнится и сохранит кеш на runner01. Вторая джоба выполнится на runner02, на нём тоже не найдёт кеш и отработает без него. Результаты кеша сохранит на runner02. Третья джоба Lint обнаружит кеш на runner01 и будет использовать его (pull). А после выполнения обновит кеш актуальными файлами (push).
Что такое артефакты?
Набор файлов, которые после выполнения джобы сохраняются на сервере GitLab. Последующие джобы скачают артефакт перед выполнением основных команд.
Build джоба создаёт артефакт DEF и сохраняет его на сервере. Вторая джоба Test скачивает артефакт с сервера перед запуском основных команд. Третья джоба Lint аналогично скачивает артефакт с сервера. То есть артефакт создаётся в первой джобе и используется в следующих. А кеш создаётся внутри каждой джобы.
Рассмотрим пример шаблона CI для Node.js, рекомендуемый GitLab:
В строке 1 указан докер-образ, который будет использоваться во всех джобах. Первая проблема — использование тега latest. Это приводит к тому, что у нас нет воспроизводимости сборок. Тег всегда указывает на последний релиз Node.js. Если в GitLab-раннере настроен кеш для докер-образов, при первом запуске будет скачан образ, а все последующие запуски будут обращаться к локально доступному образу. Получается, даже если нода обновиться с версии XX на YY, наш пайплайн об этом не узнает. Поэтому всегда указываем версию образа. И не просто релизную ветку (node:14), а версию целиком (node:14.2.5).
Строку 2 нужно рассматривать вместе с 3 и 4. Для кеширования указан каталог node_modules, и в каждой джобе выполняется установка пакетов (npm install). Установка должна происходить быстрее, потому что пакеты будут доступны внутри node_modules. Так как для кеша не указан ключ (ключевое слово key), будет использовано слово default. Это значит, что кеш будет постоянный, общий для всех веток.
Напомню, наша задача — сохранить воспроизводимость работы пайплайна. Пайплайн, запущенный сегодня, должен одинаково отработать и через год.
NPM хранит зависимости в двух файлах — package.json и package-lock.json. Если использовать package.json, принцип воспроизводимости нарушается, потому что при запуске `npm install`, пакетный менеджер будет ставить последние минорные апдейты при обнаружении нестрогих зависимостей. Чтобы зафиксировать дерево зависимостей, используем файл package-lock.json. Там строго указаны все версии пакетов.
Но есть еще одна проблема, `npm install` переписывает package-lock.json, а это совсем не то поведение, которое мы ожидаем. Поэтому используем специальную команду npm ci. Её принцип такой:
- удалить каталог node_modules;
- установить пакеты из package-lock.json.
А как быть с кешем, если node_modules каждый раз будет удаляться? Для корректной работы npm, указываем путь к кешу через переменную окружения npm_config_cache .
И последнее, в конфиге нет явного указания стейджей, внутри которых выполняются джобы. По умолчанию джоба выполняется внутри стадии test. Получается, две джобы будут выполняться параллельно. Отлично! Добавим указание стейджей и исправим все недочеты.
Что получилось после первой итерации правок:
Получилось построить воспроизводимый пайплайн. Осталось два минуса. Первый — кеш объявлен общим. Значит внутри каждой джобы будет скачиваться кеш и выгружаться новая версия кеша после выполнения джобы (pull-push). Хорошей практикой считается обновление кеша только один раз внутри пайплайна. Второй минус — установка зависимостей происходит внутри каждой джобы, это лишняя трата времени.
Теперь, чтобы подключить кеш, нужно явно унаследовать джобу через ключевое слово extends.
Здесь устанавливаем зависимости npm и используем кеш, описанный в скрытой джобе dependencies_cache. Явным образом указываем, что хотим обновить кеш через pull-push policy. Для артефакта указываем короткое время жизни (1 час). Сам по себе артефакт никакой ценности не несёт, и нет смысла хранить его на сервере GitLab.
Теперь пайплайн будет выглядеть так:
Мы научились различать области применения кеша и артефактов и смогли построить воспроизводимый пайплайн, который работает предсказуемо и эффективно использует все ресурсы. Эта статья разбирает большой пласт реальных ошибок, которые допускают при настройке CI в GitLab.
Всем привет!
Сегодня я решил написать короткую заметку о своем опыте использования кэша в GitLab CI.
Зачем это нужно
Есть у меня небольшой pet-project на котором я обычно обкатываю различные нововведения. Репозиторий проекта хранится в GitLab и там же в CI настроены две задачи - на запуск тестов и на деплой.
Задача с тестами проходила довольно быстро – примерно за 2 минуты. Но каждый раз я задумывался о том что GitLab-runner каждый раз выполняет одно и то же действие с установкой Python-зависимостей.
Да, с одной стороны это гарантирует воспроизводимость сборки и бережет от возможных проблем с отсутствием нужного пакета в каталоге пакетов в самый ответственный момент (привет leftpad и mimemagick 😄).
Но с другой стороны у меня это всего лишь pet-project для которого все это некритично. Поэтому я решил прикрутить кэш для зависимостей.
Проект на котором я все тестировал написан на Django. Для управления зависимостей я использую poetry и через него же активирую virtualenv.
Как выглядел .gitlab-ci.yml до внесения изменений
Здесь у меня устанавливаются пакеты в Debian, затем из pip устанавливается poetry и потом poetry доустанавливает необходимые пакеты для проекта.
Как стал выглядеть .gitlab-ci.yml после изменений
Я добавил настройки указывающие для pip и poetry директории в которых нужно хранить установленные пакеты. Затем добавил эти директории в директиву cache и в качестве ключа указал два файла - poetry.lock и .gitlab-ci.yml
Это означает что в случае если эти два файла не изменялись то установленные зависимости берутся из кэша, в обратном случае мы все устанавливаем заново и кэшируем.
Что изменилось
Время работы задачи с тестами снизилось с двух минут до одной. Распаковка закэшированных директорий также занимает время, но это происходит намного быстрее чем установка пакетов из PyPi. Если бы у меня было побольше зависимостей на проекте то ускорение было бы еще более ощутимым.
На этом скриншоте можно увидеть как устанавливается poetry и все зависимости достаются из кэша.
А тут видно что poetry install рапортует о том что никаких новых зависимостей устанавливать не нужно.
Выводы
Кэширование на CI это мощная штука позволяющая экономить ресурсы и время.
Также для серьезного продакшна можно настроить более сложный конфиг и на каких-то ветках не использовать кэширование. В этом случае мы получаем и производительность и надежность.
Есть еще один вариант - это собирать Docker-контейнеры со всеми зависимостями, класть их в registry и потом использовать в CI. Я думаю на каком-то проекте стоит попробовать и его)
Читайте также: