{"meta":{"title":"Maven を使用したJavaのビルドとテスト","intro":"Maven を使用してJava プロジェクトをビルドしてテストするために、GitHub Actionsで継続的インテグレーション (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/java-with-maven","title":"Maven でのJava"}],"documentType":"article"},"body":"# Maven を使用したJavaのビルドとテスト\n\nMaven を使用してJava プロジェクトをビルドしてテストするために、GitHub Actionsで継続的インテグレーション (CI) ワークフローを作成する方法について説明します。\n\n## はじめに\n\nこのガイドでは、Maven ソフトウェア プロジェクト管理ツールを使用して、Java プロジェクトの継続的インテグレーション (CI) を実行するワークフローを作成する方法について説明します。 作成するワークフローによって、プルリクエストに対するコミットがデフォルトブランチに対してビルドあるいはテストの失敗を引き起こしたことを見ることができるようになります。このアプローチは、コードが常に健全であることを保証するための役に立ちます。 CIワークフローをキャッシュ ファイルに拡張して、ワークフローの実行による成果物をアップロードするようにもできます。\n\nGitHubホストされているランナーには、Java開発キット (JDK) と Maven を含む、プレインストールされたソフトウェアを含むツール キャッシュがあります。 JDK と Maven に関するソフトウェアとプレインストールされたバージョンの一覧については、「[GitHub ホステッド ランナー](/ja/enterprise-cloud@latest/actions/concepts/runners/github-hosted-runners#preinstalled-software-for-github-owned-images)」を参照してください。\n\n## 前提条件\n\nYAML と GitHub Actionsの構文について理解している必要があります。 詳細については、以下を参照してください:\n\n* [GitHub Actions　のワークフロー構文](/ja/enterprise-cloud@latest/actions/reference/workflows-and-actions/workflow-syntax)\n* [ワークフローの書き込み](/ja/enterprise-cloud@latest/actions/how-tos/write-workflows)\n\nJavaと Maven フレームワークの基本的な理解をお勧めします。 詳細については、Maven ドキュメントの [Maven 使用開始ガイド](https://maven.apache.org/guides/getting-started/index.html)に関するページを参照してください。\n\n## Maven ワークフロー テンプレートの使用\n\nすぐに開始するには、リポジトリの `.github/workflows` ディレクトリにワークフロー テンプレートを追加します。\n\nGitHubには、Maven プロジェクトを使用するほとんどのJavaで動作する Maven 用のワークフロー テンプレートが用意されています。 このガイドの以降のセクションでは、このワークフロー テンプレートをカスタマイズする方法の例を示します。\n\n1. GitHub で、リポジトリのメイン ページに移動します。\n\n2. リポジトリ名の下にある **\\[ Actions]** をクリックします。\n\n ![\"github/docs\" リポジトリのタブのスクリーンショット。 \\[アクション\\] タブがオレンジ色の枠線で強調表示されています。](/assets/images/help/repository/actions-tab-global-nav-update.png)\n\n3. ワークフローが既にリポジトリ内にある場合は、 **\\[新しいワークフロー]** をクリックします。\n\n4. \\[ワークフローの選択] ページには、推奨されるワークフロー テンプレートの選択が表示されます。 \"Maven でJava\" を検索します。\n\n5. \"Maven を使用したJava\" ワークフローで、**Configure** をクリックします。\n\n6. 必要に応じてワークフローを編集します。 たとえば、Javaバージョンを変更します。\n\n7. **\\[Commit changes]** をクリックします。\n\n`maven.yml` ワークフロー ファイルがリポジトリの`.github/workflows` ディレクトリに追加されます。\n\n### Javaのバージョンとアーキテクチャの指定\n\nワークフロー テンプレートで x64 プラットフォーム用の OpenJDK 8 を含むように `PATH` を設定します。 異なるバージョンの Java を使用する場合、あるいは異なるアーキテクチャ (`x64` または `x86`) をターゲットとする場合、`setup-java` アクションを使って異なる Java ランタイム環境を選択できます。\n\nたとえば、x64 プラットフォームに対して Adoptium によって提供される JDK のバージョン 11 を使用するには、`setup-java` アクションを使用して、`java-version`、`distribution`、`architecture` パラメーターを `'11'`、`'temurin'`、`x64` に設定します。\n\n```yaml copy\nsteps:\n - uses: actions/checkout@v6\n - name: Set up JDK 11 for x64\n uses: actions/setup-java@v4\n with:\n java-version: '11'\n distribution: 'temurin'\n architecture: x64\n```\n\n詳細については、「[`setup-java`](https://github.com/actions/setup-java) アクション」を参照してください。\n\n## コードのビルドとテスト\n\nローカルで使うのと同じコマンドを、コードのビルドとテストに使えます。\n\nワークフロー テンプレートでは、既定で `package` ターゲットが実行されます。 デフォルトのMavenの設定では、このコマンドは依存関係をダウンロードし、クラスをビルドし、テストを実行し、たとえばJARファイルのような配布可能なフォーマットにクラスをパッケージします。\n\nプロジェクトのビルドに異なるコマンドを使ったり、異なるターゲットを使いたいのであれば、それらを指定できます。 たとえば、`verify` ファイルで構成されている `pom-ci.xml` ターゲットを実行できます。\n\n```yaml copy\nsteps:\n - uses: actions/checkout@v6\n - uses: actions/setup-java@v4\n with:\n java-version: '17'\n distribution: 'temurin'\n - name: Run the Maven verify phase\n run: mvn --batch-mode --update-snapshots verify\n```\n\n## 依存関係のキャッシング\n\nワークフローの実行速度を上げるために、依存関係をキャッシュすることもできます。 実行に成功すると、ローカルの Maven リポジトリはキャッシュに格納されます。 その後のワークフローの実行では、キャッシュがリストアされ、依存関係をリモートのMavenリポジトリからダウンロードする必要がなくなります。\n[\n`setup-java` アクション](https://github.com/marketplace/actions/setup-java-jdk)を使用するだけで依存関係をキャッシュすることも、カスタム構成や高度な構成に対して [`cache` アクション](https://github.com/actions/cache)を使用することもできます。\n\n```yaml copy\nsteps:\n - uses: actions/checkout@v6\n - name: Set up JDK 17\n uses: actions/setup-java@v4\n with:\n java-version: '17'\n distribution: 'temurin'\n cache: maven\n - name: Build with Maven\n run: mvn --batch-mode --update-snapshots verify\n```\n\nこのワークフローでは、ランナーのホーム ディレクトリの `.m2` ディレクトリにあるローカル Maven リポジトリの内容が保存されます。 キャッシュ キーは `pom.xml` ハッシュされた内容であるため、`pom.xml` を変更するとキャッシュは無効になります。\n\n## 成果物としてのワークフローのデータのパッケージ化\n\nビルドが成功し、テストが成功したら、結果のJava パッケージをビルド成果物としてアップロードできます。 そうすれば、ビルドされたパッケージをワークフローの実行の一部として保存することになり、それらをダウンロードできるようになります。 アーティファクトを利用して、Pull Requestをマージする前にローカル環境でテストとデバッグを行うことができます。 詳しくは、「[ワークフロー成果物を使ったデータの格納と共有](/ja/enterprise-cloud@latest/actions/tutorials/store-and-share-data)」をご覧ください。\n\nMaven では、通常、JAR、EAR、WAR のような出力ファイルが `target` ディレクトリに作成されます。 それらを成果物としてアップロードするために、アップロードする成果物を含む新しいディレクトリにそれらをコピーできます。 たとえば、`staging` というディレクトリを作成できます。 その後、`upload-artifact` アクションを使用して、そのディレクトリの内容をアップロードできます。\n\n```yaml copy\nsteps:\n - uses: actions/checkout@v6\n - uses: actions/setup-java@v4\n with:\n java-version: '17'\n distribution: 'temurin'\n - run: mvn --batch-mode --update-snapshots verify\n - run: mkdir staging && cp target/*.jar staging\n - uses: actions/upload-artifact@v4\n with:\n name: Package\n path: staging\n```"}