Примечание. В GitHub Enterprise Server в настоящее время не поддерживаются средства выполнения тестов, размещенные в GitHub. Дополнительные сведения о планируемой поддержке в будущем см. в GitHub public roadmap.
Введение
В этом руководстве показано, как получить рабочий процесс непрерывной интеграции (CI), который создает и тестирует приложение Ruby. Если тесты CI проходят правильно, может потребоваться развернуть код или опубликовать пакет.
Предварительные требования
Рекомендуется иметь базовое представление о Ruby, YAML, параметрах конфигурации рабочих процессов, а также о том, как создавать файл рабочего процесса. Дополнительные сведения см. в разделе:
Использование начального рабочего процесса Ruby
GitHub предоставляет начальный рабочий процесс Ruby, который будет работать для большинства проектов Ruby. Дополнительные сведения см. в разделе Начальный рабочий процесс Ruby.
Чтобы быстро приступить к работе, добавьте начальный рабочий процесс в каталог .github/workflows своего репозитория. В показанном ниже рабочем процессе предполагается, что ветвью по умолчанию для вашего репозитория является main.
# Этот рабочий процесс использует действия, которые не сертифицированы GitHub.
# Они предоставляются сторонним поставщиком, и на них распространяются
# отдельные условия обслуживания, политика конфиденциальности и поддержка
# документации.
# GitHub рекомендует закрепить действия в фиксации SHA.
# Чтобы получить более новую версию, потребуется обновить SHA.
# Вы также можете ссылаться на тег или ветвь, однако действие может измениться без предупреждения.
name: Ruby
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Set up Ruby
uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1
with:
ruby-version: '3.1'
- name: Install dependencies
run: bundle install
- name: Run tests
run: bundle exec rake
Указание версии Ruby
Самый простой способ указать версию Ruby заключается в использовании действия ruby/setup-ruby, предоставляемого организацией Ruby на GitHub. Это действие добавляет любую поддерживаемую версию Ruby в PATH для каждого задания, выполняемого в рабочем процессе. Дополнительные сведения и доступные версии Ruby см. в описании ruby/setup-ruby.
Применение действия ruby/setup-ruby Ruby представляет собой рекомендуемый способ использования Ruby с GitHub Actions, так как он обеспечивает согласованное поведение в разных средствах выполнения и различных версиях Ruby.
Действие setup-ruby принимает версию Ruby в качестве входных данных и настраивает ее в средстве выполнения.
steps:
- uses: actions/checkout@v3
- uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1
with:
ruby-version: '3.1' # Not needed with a .ruby-version file
- run: bundle install
- run: bundle exec rake
Кроме того, можно проверить файл .ruby-version в корне репозитория, чтобы setup-ruby использовал определенную в этом файле версию.
Тестирование с использованием нескольких версий Ruby
Вы можете добавить матричную стратегию для запуска рабочего процесса с несколькими версиями Ruby. Например, вы можете протестировать код для последних выпусков исправлений в версиях 3.1, 3.0 и 2.7.
strategy:
matrix:
ruby-version: ['3.1', '3.0', '2.7']
Каждая версия Ruby, указанная в массиве ruby-version, создает задание, которое выполняет одни и те же действия. Контекст ${{ matrix.ruby-version }} используется для доступа к версии текущего задания. Дополнительные сведения о матричных стратегиях и контекстах см. в разделах Синтаксис рабочего процесса для GitHub Actions и Контексты.
Полный обновленный рабочий процесс с матричной стратегией может выглядеть следующим образом:
# Этот рабочий процесс использует действия, которые не сертифицированы GitHub.
# Они предоставляются сторонним поставщиком, и на них распространяются
# отдельные условия обслуживания, политика конфиденциальности и поддержка
# документации.
# GitHub рекомендует закрепить действия в фиксации SHA.
# Чтобы получить более новую версию, потребуется обновить SHA.
# Вы также можете ссылаться на тег или ветвь, однако действие может измениться без предупреждения.
name: Ruby CI
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
test:
runs-on: ubuntu-latest
strategy:
matrix:
ruby-version: ['3.1', '3.0', '2.7']
steps:
- uses: actions/checkout@v3
- name: Set up Ruby ${{ matrix.ruby-version }}
uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1
with:
ruby-version: ${{ matrix.ruby-version }}
- name: Install dependencies
run: bundle install
- name: Run tests
run: bundle exec rake
Установка зависимостей с использованием средства увязки в пакеты
Действие setup-ruby установит средство увязки в пакеты автоматически. Версия определяется по файлу gemfile.lock. Если в файле блокировки отсутствует версия, будет установлена последняя совместимая версия.
steps:
- uses: actions/checkout@v3
- uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1
with:
ruby-version: '3.1'
- run: bundle install
Кэширование зависимостей
Действия setup-ruby предоставляют метод автоматической обработки кэширования пакетов между запусками.
Чтобы включить кэширование, укажите следующее.
steps:
- uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1
with:
bundler-cache: true
При этом средство увязки в пакеты будет настроено для установки пакетов в vendor/cache. Для каждого успешного выполнения рабочего процесса эта папка будет кэширована GitHub Actions и повторно скачана для последующих выполнений рабочего процесса. Хэш файла gemfile.lock и версия Ruby используются в качестве ключа кэша. Если вы устанавливаете новые пакеты или изменяете версию, кэш станет недействительным, а средство увязки в пакеты выполнит новую установку.
Кэширование без использования setup-ruby
Для более широкого контроля над кэшированием можно напрямую использовать действие actions/cache. Дополнительные сведения см. в разделе Кэширование зависимостей для ускорения рабочих процессов.
steps:
- uses: actions/cache@v3
with:
path: vendor/bundle
key: ${{ runner.os }}-gems-${{ hashFiles('**/Gemfile.lock') }}
restore-keys: |
${{ runner.os }}-gems-
- name: Bundle install
run: |
bundle config path vendor/bundle
bundle install --jobs 4 --retry 3
Если вы используете матричную сборку, потребуется включить матричные переменные в ключ кэша. Например, если у вас есть матричная стратегия для разных версий ruby (matrix.ruby-version) и различных операционных систем (matrix.os), шаги рабочего процесса могут выглядеть следующим образом:
steps:
- uses: actions/cache@v3
with:
path: vendor/bundle
key: bundle-use-ruby-${{ matrix.os }}-${{ matrix.ruby-version }}-${{ hashFiles('**/Gemfile.lock') }}
restore-keys: |
bundle-use-ruby-${{ matrix.os }}-${{ matrix.ruby-version }}-
- name: Bundle install
run: |
bundle config path vendor/bundle
bundle install --jobs 4 --retry 3
Матричное тестирование кода
В следующем примере выполняется матричное тестирование всех стабильных выпусков и головных версий MRI, JRuby и TruffleRuby на базе Ubuntu и macOS.
# Этот рабочий процесс использует действия, которые не сертифицированы GitHub.
# Они предоставляются сторонним поставщиком, и на них распространяются
# отдельные условия обслуживания, политика конфиденциальности и поддержка
# документации.
# GitHub рекомендует закрепить действия в фиксации SHA.
# Чтобы получить более новую версию, потребуется обновить SHA.
# Вы также можете ссылаться на тег или ветвь, однако действие может измениться без предупреждения.
name: Matrix Testing
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
test:
runs-on: ${{ matrix.os }}-latest
strategy:
fail-fast: false
matrix:
os: [ubuntu, macos]
ruby: [2.5, 2.6, 2.7, head, debug, jruby, jruby-head, truffleruby, truffleruby-head]
continue-on-error: ${{ endsWith(matrix.ruby, 'head') || matrix.ruby == 'debug' }}
steps:
- uses: actions/checkout@v3
- uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1
with:
ruby-version: ${{ matrix.ruby }}
- run: bundle install
- run: bundle exec rake
Анализ кода
В следующем примере выполняется установка rubocop и его использование для анализа кода всех файлов. Дополнительные сведения см. в описании RuboCop. Вы можете настроить Rubocop, чтобы задать конкретные правила анализа.
# Этот рабочий процесс использует действия, которые не сертифицированы GitHub.
# Они предоставляются сторонним поставщиком, и на них распространяются
# отдельные условия обслуживания, политика конфиденциальности и поддержка
# документации.
# GitHub рекомендует закрепить действия в фиксации SHA.
# Чтобы получить более новую версию, потребуется обновить SHA.
# Вы также можете ссылаться на тег или ветвь, однако действие может измениться без предупреждения.
name: Linting
on: [push]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1
with:
ruby-version: 2.6
- run: bundle install
- name: Rubocop
run: rubocop
Публикация пакетов
Вы можете настроить рабочий процесс для публикации пакета Ruby в любом подходящем реестре пакетов после прохождения тестов CI.
Вы можете хранить любые маркеры доступа или учетные данные, необходимые для публикации пакета, с помощью секретов репозитория. В следующем примере создается пакет, который публикуется в GitHub Package Registry и RubyGems.
# Этот рабочий процесс использует действия, которые не сертифицированы GitHub.
# Они предоставляются сторонним поставщиком, и на них распространяются
# отдельные условия обслуживания, политика конфиденциальности и поддержка
# документации.
# GitHub рекомендует закрепить действия в фиксации SHA.
# Чтобы получить более новую версию, потребуется обновить SHA.
# Вы также можете ссылаться на тег или ветвь, однако действие может измениться без предупреждения.
name: Ruby Gem
on:
# Manually publish
workflow_dispatch:
# Alternatively, publish whenever changes are merged to the `main` branch.
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
build:
name: Build + Publish
runs-on: ubuntu-latest
permissions:
packages: write
contents: read
steps:
- uses: actions/checkout@v3
- name: Set up Ruby 2.6
uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1
with:
ruby-version: 2.6
- run: bundle install
- name: Publish to GPR
run: |
mkdir -p $HOME/.gem
touch $HOME/.gem/credentials
chmod 0600 $HOME/.gem/credentials
printf -- "---\n:github: ${GEM_HOST_API_KEY}\n" > $HOME/.gem/credentials
gem build *.gemspec
gem push --KEY github --host https://rubygems.pkg.github.com/${OWNER} *.gem
env:
GEM_HOST_API_KEY: "Bearer ${{secrets.GITHUB_TOKEN}}"
OWNER: ${{ github.repository_owner }}
- name: Publish to RubyGems
run: |
mkdir -p $HOME/.gem
touch $HOME/.gem/credentials
chmod 0600 $HOME/.gem/credentials
printf -- "---\n:rubygems_api_key: ${GEM_HOST_API_KEY}\n" > $HOME/.gem/credentials
gem build *.gemspec
gem push *.gem
env:
GEM_HOST_API_KEY: "${{secrets.RUBYGEMS_AUTH_TOKEN}}"