Skip to main content
We publish frequent updates to our documentation, and translation of this page may still be in progress. For the most current information, please visit the English documentation.

Building and testing Ruby

You can create a continuous integration (CI) workflow to build and test your Ruby project.

Введение

В этом руководстве показано, как получить рабочий процесс непрерывной интеграции (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@359bebbc29cbe6c87da6bc9ea3bc930432750108
        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@359bebbc29cbe6c87da6bc9ea3bc930432750108
  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 }} используется для доступа к версии текущего задания. Дополнительные сведения о матричных стратегиях и контекстах см. в разделах Workflow syntax for GitHub Actions и Contexts.

Полный обновленный рабочий процесс с матричной стратегией может выглядеть следующим образом:

# Этот рабочий процесс использует действия, которые не сертифицированы 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@359bebbc29cbe6c87da6bc9ea3bc930432750108
        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@359bebbc29cbe6c87da6bc9ea3bc930432750108
  with:
    ruby-version: '3.1'
- run: bundle install

Кэширование зависимостей

Действия setup-ruby предоставляют метод автоматической обработки кэширования пакетов между запусками.

Чтобы включить кэширование, укажите следующее.

steps:
- uses: ruby/setup-ruby@359bebbc29cbe6c87da6bc9ea3bc930432750108
    with:
      bundler-cache: true

При этом средство увязки в пакеты будет настроено для установки пакетов в vendor/cache. Для каждого успешного выполнения рабочего процесса эта папка будет кэширована GitHub Actions и повторно скачана для последующих выполнений рабочего процесса. Хэш файла gemfile.lock и версия Ruby используются в качестве ключа кэша. Если вы устанавливаете новые пакеты или изменяете версию, кэш станет недействительным, а средство увязки в пакеты выполнит новую установку.

Кэширование без использования setup-ruby

Для более широкого контроля над кэшированием можно напрямую использовать действие actions/cache. Дополнительные сведения см. в разделе Caching dependencies to speed up workflows.

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@477b21f02be01bcb8030d50f37cfec92bfa615b6
        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@477b21f02be01bcb8030d50f37cfec92bfa615b6
        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@477b21f02be01bcb8030d50f37cfec92bfa615b6
        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}}"