{"meta":{"title":"Создание и тестирование для Ruby","intro":"Вы можете создать рабочий процесс непрерывной интеграции для сборки и тестирования проекта Ruby.","product":"GitHub Actions","breadcrumbs":[{"href":"/ru/actions","title":"GitHub Actions"},{"href":"/ru/actions/tutorials","title":"Учебники"},{"href":"/ru/actions/tutorials/build-and-test-code","title":"Сборка и тестирование кода"},{"href":"/ru/actions/tutorials/build-and-test-code/ruby","title":"Ruby"}],"documentType":"article"},"body":"# Создание и тестирование для Ruby\n\nВы можете создать рабочий процесс непрерывной интеграции для сборки и тестирования проекта Ruby.\n\n\n## Introduction\n\nThis guide shows you how to create a continuous integration (CI) workflow that builds and tests a Ruby application. If your CI tests pass, you may want to deploy your code or publish a gem.\n\n## Prerequisites\n\nWe recommend that you have a basic understanding of Ruby, YAML, workflow configuration options, and how to create a workflow file. For more information, see:\n\n* [Learn GitHub Actions](/en/actions/learn-github-actions)\n* [Ruby in 20 minutes](https://www.ruby-lang.org/en/documentation/quickstart/)\n\n## Using a Ruby workflow template\n\nTo get started quickly, add a workflow template to the `.github/workflows` directory of your repository.\n\nGitHub provides a workflow template for Ruby that should work for most Ruby projects. The subsequent sections of this guide give examples of how you can customize this workflow template.\n\n1. On GitHub, navigate to the main page of the repository.\n\n2. Under your repository name, click ** Actions**.\n\n ![Screenshot of the tabs for the \"github/docs\" repository. The \"Actions\" tab is highlighted with an orange outline.](/assets/images/help/repository/actions-tab-global-nav-update.png)\n\n3. If you already have a workflow in your repository, click **New workflow**.\n\n4. The \"Choose a workflow\" page shows a selection of recommended workflow templates. Search for \"ruby\".\n\n5. Filter the selection of workflows by clicking **Continuous integration**.\n\n6. On the \"Ruby\" workflow, click **Configure**.\n\n7. Edit the workflow as required. For example, change the Ruby versions you want to use.\n\n > \\[!NOTE]\n >\n > * This workflow template contains an action that is not certified by GitHub. Actions provided by third parties are governed by separate terms of service, privacy policy, and support documentation.\n > * If you use actions from third parties you should use a version specified by a commit SHA. If the action is revised and you want to use the newer version, you will need to update the SHA. You can specify a version by referencing a tag or a branch, however the action may change without warning. For more information, see [Secure use reference](/en/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions).\n\n8. Click **Commit changes**.\n\n The `ruby.yml` workflow file is added to the `.github/workflows` directory of your repository.\n\n## Specifying the Ruby version\n\nThe easiest way to specify a Ruby version is by using the `ruby/setup-ruby` action provided by the Ruby organization on GitHub. The action adds any supported Ruby version to `PATH` for each job run in a workflow. For more information and available Ruby versions, see [`ruby/setup-ruby`](https://github.com/ruby/setup-ruby).\n\nUsing Ruby's `ruby/setup-ruby` action is the recommended way of using Ruby with GitHub Actions because it ensures consistent behavior across different runners and different versions of Ruby.\n\nThe `setup-ruby` action takes a Ruby version as an input and configures that version on the runner.\n\n```yaml\n# This workflow uses actions that are not certified by GitHub.\n# They are provided by a third-party and are governed by\n# separate terms of service, privacy policy, and support\n# documentation.\nsteps:\n- uses: actions/checkout@v6\n- uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1\n with:\n ruby-version: '3.1' # Not needed with a .ruby-version file\n- run: bundle install\n- run: bundle exec rake\n```\n\nAlternatively, you can check a `.ruby-version` file into the root of your repository and `setup-ruby` will use the version defined in that file.\n\n## Testing with multiple versions of Ruby\n\nYou can add a matrix strategy to run your workflow with more than one version of Ruby. For example, you can test your code against the latest patch releases of versions 3.1, 3.0, and 2.7.\n\n```yaml\nstrategy:\n matrix:\n ruby-version: ['3.1', '3.0', '2.7']\n```\n\nEach version of Ruby specified in the `ruby-version` array creates a job that runs the same steps. The `${{ matrix.ruby-version }}` context is used to access the current job's version. For more information about matrix strategies and contexts, see [Workflow syntax for GitHub Actions](/en/actions/using-workflows/workflow-syntax-for-github-actions) and [Contexts reference](/en/actions/learn-github-actions/contexts).\n\nThe full updated workflow with a matrix strategy could look like this:\n\n```yaml\n# This workflow uses actions that are not certified by GitHub.\n# They are provided by a third-party and are governed by\n# separate terms of service, privacy policy, and support\n# documentation.\n\n# GitHub recommends pinning actions to a commit SHA.\n# To get a newer version, you will need to update the SHA.\n# You can also reference a tag or branch, but the action may change without warning.\n\nname: Ruby CI\n\non:\n push:\n branches: [ main ]\n pull_request:\n branches: [ main ]\n\njobs:\n test:\n\n runs-on: ubuntu-latest\n\n strategy:\n matrix:\n ruby-version: ['3.1', '3.0', '2.7']\n\n steps:\n - uses: actions/checkout@v6\n - name: Set up Ruby ${{ matrix.ruby-version }}\n uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1\n with:\n ruby-version: ${{ matrix.ruby-version }}\n - name: Install dependencies\n run: bundle install\n - name: Run tests\n run: bundle exec rake\n```\n\n## Installing dependencies with Bundler\n\nThe `setup-ruby` action will automatically install bundler for you. The version is determined by your `gemfile.lock` file. If no version is present in your lockfile, then the latest compatible version will be installed.\n\n```yaml\n# This workflow uses actions that are not certified by GitHub.\n# They are provided by a third-party and are governed by\n# separate terms of service, privacy policy, and support\n# documentation.\nsteps:\n- uses: actions/checkout@v6\n- uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1\n with:\n ruby-version: '3.1'\n- run: bundle install\n```\n\n### Caching dependencies\n\nThe `setup-ruby` actions provides a method to automatically handle the caching of your gems between runs.\n\nTo enable caching, set the following.\n\n```yaml\n# This workflow uses actions that are not certified by GitHub.\n# They are provided by a third-party and are governed by\n# separate terms of service, privacy policy, and support\n# documentation.\nsteps:\n- uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1\n with:\n bundler-cache: true\n```\n\nThis will configure bundler to install your gems to `vendor/cache`. For each successful run of your workflow, this folder will be cached by GitHub Actions and re-downloaded for subsequent workflow runs. A hash of your `gemfile.lock` and the Ruby version are used as the cache key. If you install any new gems, or change a version, the cache will be invalidated and bundler will do a fresh install.\n\n**Caching without setup-ruby**\n\nFor greater control over caching, you can use the `actions/cache` action directly. For more information, see [Dependency caching reference](/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows).\n\n```yaml\nsteps:\n- uses: actions/cache@v4\n with:\n path: vendor/bundle\n key: ${{ runner.os }}-gems-${{ hashFiles('**/Gemfile.lock') }}\n restore-keys: |\n ${{ runner.os }}-gems-\n- name: Bundle install\n run: |\n bundle config path vendor/bundle\n bundle install --jobs 4 --retry 3\n```\n\nIf you're using a matrix build, you will want to include the matrix variables in your cache key. For example, if you have a matrix strategy for different ruby versions (`matrix.ruby-version`) and different operating systems (`matrix.os`), your workflow steps might look like this:\n\n```yaml\nsteps:\n- uses: actions/cache@v4\n with:\n path: vendor/bundle\n key: bundle-use-ruby-${{ matrix.os }}-${{ matrix.ruby-version }}-${{ hashFiles('**/Gemfile.lock') }}\n restore-keys: |\n bundle-use-ruby-${{ matrix.os }}-${{ matrix.ruby-version }}-\n- name: Bundle install\n run: |\n bundle config path vendor/bundle\n bundle install --jobs 4 --retry 3\n```\n\n## Matrix testing your code\n\nThe following example matrix tests all stable releases and head versions of MRI, JRuby and TruffleRuby on Ubuntu and macOS.\n\n```yaml\n# This workflow uses actions that are not certified by GitHub.\n# They are provided by a third-party and are governed by\n# separate terms of service, privacy policy, and support\n# documentation.\n\n# GitHub recommends pinning actions to a commit SHA.\n# To get a newer version, you will need to update the SHA.\n# You can also reference a tag or branch, but the action may change without warning.\n\nname: Matrix Testing\n\non:\n push:\n branches: [ main ]\n pull_request:\n branches: [ main ]\n\njobs:\n test:\n runs-on: ${{ matrix.os }}-latest\n strategy:\n fail-fast: false\n matrix:\n os: [ubuntu, macos]\n ruby: [2.5, 2.6, 2.7, head, debug, jruby, jruby-head, truffleruby, truffleruby-head]\n continue-on-error: ${{ endsWith(matrix.ruby, 'head') || matrix.ruby == 'debug' }}\n steps:\n - uses: actions/checkout@v6\n - uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1\n with:\n ruby-version: ${{ matrix.ruby }}\n - run: bundle install\n - run: bundle exec rake\n```\n\n## Linting your code\n\nThe following example installs `rubocop` and uses it to lint all files. For more information, see [RuboCop](https://github.com/rubocop-hq/rubocop). You can [configure Rubocop](https://docs.rubocop.org/rubocop/configuration.html) to decide on the specific linting rules.\n\n```yaml\n# This workflow uses actions that are not certified by GitHub.\n# They are provided by a third-party and are governed by\n# separate terms of service, privacy policy, and support\n# documentation.\n\n# GitHub recommends pinning actions to a commit SHA.\n# To get a newer version, you will need to update the SHA.\n# You can also reference a tag or branch, but the action may change without warning.\n\nname: Linting\n\non: [push]\n\njobs:\n test:\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v6\n - uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1\n with:\n ruby-version: '2.6'\n - run: bundle install\n - name: Rubocop\n run: rubocop -f github\n```\n\nSpecifying `-f github` means that the RuboCop output will be in GitHub's annotation format. Any linting errors will show inline in the **Files changed** tab of the pull request that introduces them.\n\n## Publishing Gems\n\nYou can configure your workflow to publish your Ruby package to any package registry you'd like when your CI tests pass.\n\nYou can store any access tokens or credentials needed to publish your package using repository secrets. The following example creates and publishes a package to `GitHub Package Registry` and `RubyGems`.\n\n```yaml\n# This workflow uses actions that are not certified by GitHub.\n# They are provided by a third-party and are governed by\n# separate terms of service, privacy policy, and support\n# documentation.\n\n# GitHub recommends pinning actions to a commit SHA.\n# To get a newer version, you will need to update the SHA.\n# You can also reference a tag or branch, but the action may change without warning.\n\nname: Ruby Gem\n\non:\n # Manually publish\n workflow_dispatch:\n # Alternatively, publish whenever changes are merged to the `main` branch.\n push:\n branches: [ main ]\n pull_request:\n branches: [ main ]\n\njobs:\n build:\n name: Build + Publish\n runs-on: ubuntu-latest\n permissions:\n packages: write\n contents: read\n\n steps:\n - uses: actions/checkout@v6\n - name: Set up Ruby 2.6\n uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1\n with:\n ruby-version: '2.6'\n - run: bundle install\n\n - name: Publish to GPR\n run: |\n mkdir -p $HOME/.gem\n touch $HOME/.gem/credentials\n chmod 0600 $HOME/.gem/credentials\n printf -- \"---\\n:github: ${GEM_HOST_API_KEY}\\n\" > $HOME/.gem/credentials\n gem build *.gemspec\n gem push --KEY github --host https://rubygems.pkg.github.com/${OWNER} *.gem\n env:\n GEM_HOST_API_KEY: \"Bearer ${{secrets.GITHUB_TOKEN}}\"\n OWNER: ${{ github.repository_owner }}\n\n - name: Publish to RubyGems\n run: |\n mkdir -p $HOME/.gem\n touch $HOME/.gem/credentials\n chmod 0600 $HOME/.gem/credentials\n printf -- \"---\\n:rubygems_api_key: ${GEM_HOST_API_KEY}\\n\" > $HOME/.gem/credentials\n gem build *.gemspec\n gem push *.gem\n env:\n GEM_HOST_API_KEY: \"${{secrets.RUBYGEMS_AUTH_TOKEN}}\"\n```"}