ruby/setup-ruby
, а второй — actions/cache
.
- actions/cache — это популярное решение для кеширования гемов Ruby.
- ruby/setup-ruby — это решение, направленное на установку конкретной версии Ruby и на кеширование гемов Ruby с помощью бандлера. Фактически, речь идёт о двух возможностях одного «экшена» (того, что в терминологии GitHub Actions называется «action»).
Actions/cache — кеширование зависимостей и больше ничего
Actions/cache — это популярное решение, которое может быть использовано для размещения данных в кеше и для их извлечения из кеша при очередном запуске процесса сборки проекта в CI-системе. Часто этот экшен используют для RoR-проектов, в которых, кроме того, для управления версиями Ruby в GitHub Actions, используется экшн
actions/setup-ruby
.
Рассмотрим пример конфигурационного файла для организации кеширования в GitHub Actions, в котором используется actions/cache
:
# .github/workflows/main.yml
name: Main
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions/cache@v2
with:
path: vendor/bundle
key: $-gems-$
restore-keys: |
$-gems-
- name: Bundle install
env:
RAILS_ENV: test
run: |
bundle config path vendor/bundle
bundle install --jobs 4 --retry 3
Разберём основные особенности этого файла:
- Нужно указать путь к директории, которую требуется кешировать. В нашем случае это —
vendor/bundle
. - Кроме того, тут мы генерируем уникальный ключ (
key
) кеша, применяя при этом сведения о версии операционной системы и о файлеGemfile.lock
. Изменение версии операционной системы или установка нового гема, из-за чего изменяетсяGemfile.lock
, приводит к генерированию нового значенияkey
. - Далее, надо настроить бандлер так, чтобы он устанавливал бы все наши гемы Ruby в директорию
vendor/bundle
. - Тут можно использовать следующие параметры бандлера:
Если вам интересно взглянуть на полные YAML-файлы с настройками GitHub Actions для Rail-проектов — вот, вот, вот и вот — несколько наших статей на эту тему.
Ruby/setup-ruby — установка Ruby и кеширование гемов
Выше мы упоминали о том, что в RoR-проектах часто используется
actions/setup-ruby
. Но экшен actions/setup-ruby
был объявлен устаревшим. Вместо него в наши дни рекомендуется пользоваться экшеном ruby/setup-ruby
. В нём, помимо прочих возможностей, имеется и возможность кеширования данных. Вот как выглядит конфигурационный файл, рассчитанный на использование ruby/setup-ruby
:
# .github/workflows/main.yml
name: Main
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: ruby/setup-ruby@v1
with:
# Не нужно при наличии файла.ruby-version
ruby-version: 2.7
# запускает 'bundle install' и автоматически кеширует установленные гемы
bundler-cache: true
# запуск RSpec-тестов
- run: bundle exec rspec
Как видите, этот вариант организации кеширования гемов проще того, что мы описали в предыдущем разделе. И тут, кроме того, в нашем распоряжении оказывается система управления версиями Ruby. В сущности, если говорить о кешировании гемов, всё сводится к добавлению в конфигурационный файл строчки
bundler-cache: true
.
А вот что можно узнать, обратившись к документации по ruby/setup-ruby
:
Можно, кроме того, кешировать гемы вручную, но поступать так не рекомендуется. При таком подходе, во-первых, увеличиваются объёмы конфигурационных файлов, а во-вторых — вручную очень сложно настроить кеширование правильно. В расчёт нужно принять много всего, а это значит, что actions/cache никогда не бывает достаточно для кеширования гемов (например — речь идёт о неполных ключах кеша, об удалении старых гемов при восстановлении данных с использованием ключа, отличающегося от текущего, о корректном хешировании .lock-файлов, сведения об изменениях которых не внесены в систему контроля версий, об учёте версии ОС, о принятии во внимание вопросов ABI-совместимости для ruby-head и так далее). Поэтому, пожалуйста, вместо ручной настройки кеширования, пользуйтесь опцией bundler-cache: true…
Итоги
Мы рассмотрели два способа кеширования гемов Ruby в CI GitHub Actions. Надеемся, что тот, кто нуждается в ускорении сборки Ruby-проектов, нашёл здесь пищу для размышлений. Но, конечно, есть и другие способы ускорения CI-конвейеров, например — параллельное выполнение тестов.
Пользуетесь ли вы GitHub Actions?
Комментариев нет:
Отправить комментарий