{"meta":{"title":"Rubyでのビルドとテスト","intro":"Rubyプロジェクトのビルドとテストのための継続的インテグレーション（CI）ワークフローを作成できます。","product":"GitHub Actions","breadcrumbs":[{"href":"/ja/enterprise-cloud@latest/actions","title":"GitHub Actions"},{"href":"/ja/enterprise-cloud@latest/actions/tutorials","title":"チュートリアル"},{"href":"/ja/enterprise-cloud@latest/actions/tutorials/build-and-test-code","title":"コードのビルドとテスト"},{"href":"/ja/enterprise-cloud@latest/actions/tutorials/build-and-test-code/ruby","title":"Ruby"}],"documentType":"article"},"body":"# Rubyでのビルドとテスト\n\nRubyプロジェクトのビルドとテストのための継続的インテグレーション（CI）ワークフローを作成できます。\n\n## 概要\n\nこのガイドでは、Rubyアプリケーションのビルドとテストを行う継続的インテグレーション（CI）ワークフローの作成方法を紹介します。 CIテストにパスしたなら、コードをデプロイしたりgemを公開したりすることになるでしょう。\n\n## 前提条件\n\nRuby、YAML、ワークフローの設定オプションと、ワークフローファイルの作成方法についての基本的な知識を持っておくことをおすすめします。 詳細については、次を参照してください。\n\n* [GitHub Actions について](/ja/enterprise-cloud@latest/actions/learn-github-actions)\n* [20 分で Ruby](https://www.ruby-lang.org/en/documentation/quickstart/)\n\n## Ruby ワークフロー テンプレートの使用\n\nすぐに開始するには、リポジトリの `.github/workflows` ディレクトリにワークフロー テンプレートを追加します。\n\nGitHub は、ほとんどの Ruby プロジェクトで動作するはずの Ruby 向けワークフロー テンプレートを提供しています。 このガイドの以降のセクションでは、このワークフロー テンプレートをカスタマイズする方法の例をいくつか示します。\n\n1. GitHub で、リポジトリのメイン ページに移動します。\n\n2. リポジトリ名の下にある **\\[ Actions]** をクリックします。\n\n ![\"github/docs\" リポジトリのタブのスクリーンショット。 \\[アクション\\] タブがオレンジ色の枠線で強調表示されています。](/assets/images/help/repository/actions-tab-global-nav-update.png)\n\n3. ワークフローが既にリポジトリ内にある場合は、 **\\[新しいワークフロー]** をクリックします。\n\n4. \\[ワークフローの選択] ページには、推奨されるワークフロー テンプレートの選択肢が表示されます。 \"ruby\" を検索します。\n\n5. ```\n **[継続的インテグレーション]** をクリックし、ワークフローの選択肢をフィルター処理します。\n ```\n\n6. \"Ruby\" ワークフローで、**\\[構成]** をクリックします。\n\n7. 必要に応じてワークフローを編集します。 たとえば、使用を希望する Ruby のバージョンを変更します。\n\n > \\[!NOTE]\n >\n > * このワークフロー テンプレートでは、GitHub によって認定されていないアクションが使われます。 サード パーティによって提供されるアクションには、個別のサービス使用条件、プライバシー ポリシー、およびサポート ドキュメントが適用されます。\n > * サード パーティのアクションを使用するには、コミット SHA で指定されたバージョンを使用する必要があります。 アクションが変更された新しいバージョンを使用する場合は、SHA を更新する必要があります。 タグまたはブランチを参照してバージョンを指定できますが、アクションは警告なしに変更される可能性があります。 詳しくは、「[セキュリティで保護された使用に関するリファレンス](/ja/enterprise-cloud@latest/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions)」をご覧ください。\n\n8. ```\n **[Commit changes]** をクリックします。\n ```\n\n`ruby.yml` ワークフロー ファイルが使用中リポジトリの `.github/workflows` ディレクトリに追加されます。\n\n## Rubyのバージョンの指定\n\nRuby バージョンを指定する最も簡単な方法は、ruby 組織がGitHubに提供する `ruby/setup-ruby` アクションを使用することです。 このアクションにより、ワークフロー内の各ジョブ実行に対する `PATH` に、サポートされている Ruby のバージョンが追加されます。 詳細と使用可能な Ruby のバージョンについては、[`ruby/setup-ruby`](https://github.com/ruby/setup-ruby) を参照してください。\n\nRuby の`ruby/setup-ruby` アクションを使用すると、異なるランナーと異なるバージョンの Ruby で一貫した動作が保証されるため、GitHub Actionsで Ruby を使用することをお勧めします。\n\n```\n `setup-ruby` アクションは Ruby のバージョンを入力として受け取り、ランナー上でそのバージョンを構成します。\n```\n\n```yaml\n# このワークフローはGitHubによって認定されていないアクションを使用します。\n# それらはサードパーティによって提供され、\n# 別個の利用規約、プライバシーポリシー、\n# ドキュメントを参照してください。\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\nまたは、リポジトリのルートに `.ruby-version` ファイルをチェックインすると、そのファイルで定義されているバージョンが `setup-ruby` で使われます。\n\n## 複数のバージョンの Ruby でのテスト\n\n複数バージョンのRubyでワークフローを実行するように、マトリクス戦略を追加できます。 たとえば、バージョン 3.1、3.0、2.7 の最新のパッチ リリースに対してコードをテストできます。\n\n```yaml\nstrategy:\n matrix:\n ruby-version: ['3.1', '3.0', '2.7']\n```\n\n```\n `ruby-version` 配列で指定されている Ruby の各バージョンで、同じ手順を実行するジョブが作成されます。 現在のジョブのバージョンにアクセスするには、`${{ matrix.ruby-version }}` コンテキストが使われます。 マトリックスの戦略とコンテキストの詳細については、「[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions)」および「[AUTOTITLE](/actions/learn-github-actions/contexts)」を参照してください。\n```\n\nマトリクス戦略を持つ更新された完全なワークフローは、以下のようになるでしょう。\n\n```yaml\n# このワークフローはGitHubによって認定されていないアクションを使用します。\n# それらはサードパーティによって提供され、\n# 別個の利用規約、プライバシーポリシー、\n# ドキュメントを参照してください。\n\n# GitHub では、コミット SHA にアクションをピン留めすることが推奨されます。\n# 新しいバージョンを取得するには、SHA を更新する必要があります。\n# タグまたはブランチを参照することもできますが、アクションは警告なしに変更される可能性があります。\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## Bundlerでの依存関係のインストール\n\n```\n `setup-ruby` アクションにより、バンドルが自動的にインストールされます。 バージョンは `gemfile.lock` ファイルによって決まります。 ロックファイルにバージョンがなければ、互換性のある最新のバージョンがインストールされます。\n```\n\n```yaml\n# このワークフローはGitHubによって認定されていないアクションを使用します。\n# それらはサードパーティによって提供され、\n# 別個の利用規約、プライバシーポリシー、\n# ドキュメントを参照してください。\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### 依存関係のキャッシング\n\n```\n `setup-ruby` アクションによって実行間で gem のキャッシュを自動的に処理する方法が提供されます。\n```\n\nキャッシングを有効にするには、以下の設定をしてください。\n\n```yaml\n# このワークフローはGitHubによって認定されていないアクションを使用します。\n# それらはサードパーティによって提供され、\n# 別個の利用規約、プライバシーポリシー、\n# ドキュメントを参照してください。\nsteps:\n- uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1\n with:\n bundler-cache: true\n```\n\nこれにより、gem を `vendor/cache` にインストールするように Bundler が構成されます。 ワークフローの実行が成功するたびに、このフォルダーは GitHub Actions によってキャッシュされ、それ以降のワークフローの実行の際に再ダウンロードされます。 キャッシュのキーとして、`gemfile.lock` と Ruby バージョンが使われます。 新しいgemをインストールしたり、バージョンを変更したりすると、キャッシュは無効になり、bundlerは新しくインストールを行います。\n\n```\n **setup-ruby を使用しないキャッシュ**\n```\n\nキャッシュをより詳細に制御するために、`actions/cache` アクションを直接使用できます。 詳しくは、「[依存関係キャッシュのリファレンス](/ja/enterprise-cloud@latest/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\nマトリクスビルドを使っているなら、キャッシュのキーにマトリクスの変数を含めたくなるでしょう。 たとえば、Ruby のさまざまなバージョン (`matrix.ruby-version`) とさまざまなオペレーティング システム (`matrix.os`) に対してマトリクス戦略を使用している場合、ワークフローの手順は次のようになります。\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## コードのマトリクステスト\n\n以下の例のマトリクスは、すべての安定リリースとヘッドバージョンのMRI、JRuby、TruffleRubyをUbuntu及びmacOSでテストします。\n\n```yaml\n# このワークフローはGitHubによって認定されていないアクションを使用します。\n# それらはサードパーティによって提供され、\n# 別個の利用規約、プライバシーポリシー、\n# ドキュメントを参照してください。\n\n# GitHub では、コミット SHA にアクションをピン留めすることが推奨されます。\n# 新しいバージョンを取得するには、SHA を更新する必要があります。\n# タグまたはブランチを参照することもできますが、アクションは警告なしに変更される可能性があります。\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## コードの文法チェック\n\n次の例では、`rubocop` がインストールされ、それを使ってすべてのファイルがリントされます。 詳細については、[RuboCop](https://github.com/rubocop-hq/rubocop) を参照してください。 特定のリンティング規則を決定するように、[Rubocop を構成する](https://docs.rubocop.org/rubocop/configuration.html)ことができます。\n\n```yaml\n# このワークフローはGitHubによって認定されていないアクションを使用します。\n# それらはサードパーティによって提供され、\n# 別個の利用規約、プライバシーポリシー、\n# ドキュメントを参照してください。\n\n# GitHub では、コミット SHA にアクションをピン留めすることが推奨されます。\n# 新しいバージョンを取得するには、SHA を更新する必要があります。\n# タグまたはブランチを参照することもできますが、アクションは警告なしに変更される可能性があります。\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\n```\n `-f github` を指定すると、RuboCop の出力は GitHub の注釈形式になります。 リンティング エラーは、そのエラーが発生した pull request (プル リクエスト) の **[変更されたファイル]** タブにインラインで表示されます。\n```\n\n## gemの公開\n\nCIテストにパスしたなら、Rubyパッケージを任意のパッケージレジストリに公開するようにワークフローを設定できます。\n\nパッケージを公開するのに必要なアクセストークンや認証情報は、リポジトリシークレットを使って保存できます。 次の例では、`GitHub Package Registry` および `RubyGems` にパッケージを作成して発行します。\n\n```yaml\n# このワークフローはGitHubによって認定されていないアクションを使用します。\n# それらはサードパーティによって提供され、\n# 別個の利用規約、プライバシーポリシー、\n# ドキュメントを参照してください。\n\n# GitHub では、コミット SHA にアクションをピン留めすることが推奨されます。\n# 新しいバージョンを取得するには、SHA を更新する必要があります。\n# タグまたはブランチを参照することもできますが、アクションは警告なしに変更される可能性があります。\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```"}