ドキュメントには頻繁に更新が加えられ、その都度公開されています。本ページの翻訳はまだ未完成な部分があることをご了承ください。最新の情報については、英語のドキュメンテーションをご参照ください。本ページの翻訳に問題がある場合はこちらまでご連絡ください。

継続的インテグレーションについて

GitHub Actions で GitHub リポジトリにカスタム継続的インテグレーション(CI)ワークフローと継続的デプロイメント(CD)ワークフローを直接作成できます。

GitHub ActionsはGitHub Free、GitHub Pro、GitHub FreeのOrganization、GitHub Team、GitHub Enterprise Cloud、GitHub Enterprise Server、GitHub One、GitHub AEで利用できます。 GitHub Actionsは、レガシーのリポジトリごとのプランを使っているアカウントが所有しているプライベートリポジトリでは利用できません。 詳しい情報については「GitHubの製品」を参照してください。

ここには以下の内容があります:

継続的インテグレーションについて

継続的インテグレーション (CI) とは、ソフトウェアの開発においてコードを頻繁に共有リポジトリにコミットする手法のことです。 コードをコミットする頻度が高いほどエラーの検出が早くなり、開発者がエラーの原因を見つけるためにデバッグしなければならないコードの量も減ります。 コードの更新が頻繁であれば、ソフトウェア開発チームの他のメンバーによる変更をマージするのも、それだけ容易になります。 コードの記述により多くの時間をかけられるようになり、エラーのデバッグやマージコンフリクトの解決にかける時間が減るので、これは開発者にとって素晴らしいやり方です。

コードをリポジトリにコミットするとき、コミットによってエラーが発生しないように、コードのビルドとテストを継続的に行うことができます。 テストには、コードの文法チェッカー (スタイルフォーマットをチェックする)、セキュリティチェック、コードカバレッジ、機能テスト、その他のカスタムチェックを含めることができます。

コードをビルドしてテストするには、サーバーが必要です。 ローカルでアップデートのビルドとテストを行ってからコードをリポジトリにプッシュする方法もありますし、リポジトリ での新しいコードのコミットをチェックするCIサーバーを使用する方法もあります。

GitHub Actions を使用する継続的インテグレーションについて

GitHub Actions を利用した CI では、リポジトリ中のコードをビルドしてテストを実行できるワークフローが利用できます。 ワークフローは、GitHub でホストされている仮想マシン、または自分がホストしているマシンで実行できます。 詳しい情報については、「GitHub ホストランナーの仮想環境」および「セルフホストランナーについて」を参照してください。

CI ワークフローは、GitHub イベントが発生したとき(たとえば、新しいコードがリポジトリにプッシュされたとき)や、設定されたスケジュール、またはリポジトリディスパッチ webhook を使用して外部イベントが発生したときに実行するように設定できます。

GitHub は CI テストを実行して、プルリクエストで各テストの結果を提供するため、ブランチの変更によってエラーが発生したかどうかを確認できます。 ワークフローのテストがすべて成功すると、プッシュした変更をチームメンバーがレビューできるように、またはマージできるようになります。 テストが失敗した場合は、いずれかの変更がその原因になっている可能性があります。

リポジトリに CI を設定する際には、GitHub がリポジトリ内のコードを分析し、リポジトリ内の言語とフレームワークに基づいて CI ワークフローを推奨します。 たとえば、Node.js を使用する場合、GitHub は、Node.js パッケージをインストールしてテストを実行するテンプレートファイルを提案します。 GitHub によって提案された CI ワークフローテンプレートを使用しても、提案されたテンプレートをカスタマイズしてもかまいませんし、独自のカスタムワークフローファイルを作成して CI テストを実行することもできます。

提案された継続的インテグレーションテンプレートのスクリーンショット

プロジェクトの CI ワークフローの設定だけでなく、GitHub Actions を使用してソフトウェア開発のライフサイクル全体に渡るワークフローを作成することもできます。 たとえば、Actionを使用してプロジェクトをデプロイ、パッケージ、またはリリースすることが可能です。 詳しい情報については、「GitHub Actions について」を参照してください。

一般的な用語の定義については「GitHub Actions の中核的概念」を参照してください。

サポートされている言語

GitHub では、各種言語およびフレームワークに応じて CI ワークフローテンプレートが提供されます。

GitHub 上の actions/starter-workflows リポジトリ

ワークフロー実行をスキップする

ワークフローがトリガーされないようにする場合は、コミットメッセージにスキップ命令を追加できます。 on: push または on: pull_request でトリガーされるワークフローは、プッシュまたはプルリクエストの HEAD コミットで、次の文字列型のいずれかをコミットメッセージに追加した場合トリガーされません。

  • [skip ci]
  • [ci skip]
  • [no ci]
  • [skip actions]
  • [actions skip]

または、コミットメッセージを 2 行の空行で終了し、その後に skip-checks: true または skip-checks:true のいずれかを続けることもできます。

最初にリポジトリがパスするための特定のチェックを受けるように設定されている場合、プルリクエストをマージすることはできません。 プルリクエストをマージできるようにするには、コミットメッセージのスキップ命令なしでプルリクエストに新しいコミットをプッシュできます。

注釈: スキップ命令は、push および pull_request イベントにのみ適用されます。 たとえば、コミットメッセージに [skip ci] を追加しても、on: pull_request_target でトリガーされたワークフロー実行は停止されません。

ワークフロー実行の通知

GitHub Actionsに対するメールあるいはWeb通知を有効化すると、あなたが起動したワークフローランが完了すると通知されます。 この通知には、ワークフローランのステータス(成功、失敗、ニュートラル、キャンセルされたランが含まれます)が含まれます。 ワークフローランが失敗したときにだけ通知を受けるようにすることもできます。

Notifications for scheduled workflows are sent to the user who initially created the workflow. If a different user updates the cron syntax in the workflow file, subsequent notifications will be sent to that user instead. If a scheduled workflow is disabled and then re-enabled, notifications will be sent to the user who re-enabled the workflow rather than the user who last modified the cron syntax.

リポジトリのActionsタブでワークフローランのステータスを見ることもできます。 詳細については、「ワークフロー実行の管理」を参照してください。

ワークフロー実行のためのステータスバッジ

ステータスバッジは、ワークフローが現在失敗しているかパスしているかを示します。 ステータスバッジを追加する一般的な場所は、リポジトリのREADME.mdファイル中ですが、任意の好きなWebページに追加できます。 デフォルトでは、バッジはデフォルトブランチのステータスを示します。 特定のブランチやイベントに対するワークフローの実行のステータスを、URL中のbranch及びeventクエリパラメータを使って表示することもできます。

ステータスバッジの例

詳細は「ワークフローの設定」を参照してください。

参考リンク

Did this doc help you?

Privacy policy

Help us make these docs great!

All GitHub docs are open source. See something that's wrong or unclear? Submit a pull request.

Make a contribution

OR, learn how to contribute.