CircleCI のビルドを柔軟にしてみた ― GitHub Appsの活用
この記事でわかること
この記事では、GitHub Apps を CircleCI にインストールして、柔軟なビルドを可能にする方法を説明します。
- GitHub Apps とは？
- 私はどっちを使っている？ GitHub OAuth組織 or GitHub Apps組織
- GitHub Apps をインストールするとできること・できないこと
- GitHub Apps をインストールする方法① - 初めてCircleCIを利用する場合
- GitHub Apps をインストールする方法② - 既にGitHub OAuth組織で利用している場合
- GitHub Apps で柔軟な Trigger を設定する方法
こんにちは。CircleCIカスタマーサクセスチームの Chisato です。
最近幸せを感じた出来事は、公園の散歩中にヤマトタマムシを見つけたことです。
その堂々たる姿は、まるで高級スポーツカー。
虫が苦手な私でさえ、立ち止まって見入ってしまうほどに圧巻の美しさでした。
GitHub Apps とは？
GitHub Apps は、GitHub の機能を拡張するツールです。 GitHub Apps を使うと、GitHub で、issue を開く、pull request にコメントする、プロジェクトを管理する、といったことを行うことができます。 また、GitHub で発生するイベントに基づいて、GitHub の外部で何かを行うこともできます。 たとえば、GitHub で issue が開かれたときに、GitHub App で Slack に投稿できます。
引用：GitHub Apps について, GitHub
私はどっち？ GitHub OAuth組織 or GitHub Apps組織
自分の組織がGitHub OAuth組織 or GitHub Apps組織なのかを見分ける最も簡単な方法は、URLを見ることです。
GitHub OAuth組織の例
organization/github/ のように、organization/ 以降がVCS名になっています。
また、下記のように、github/以降がGitHubの組織名と合致します。
https://app.circleci.com/organization/github/testtest
GitHub Apps組織の例
organization/github/ のように、organization/ 以降が circleci になっています。
また、下記のように、github/以降がランダムな文字列になっています。
https://app.circleci.com/organization/circleci/TgD2...
CircleCIで GitHub OAuth組織を利用している場合、次のことができます。
- 既存のGitHub OAuth組織内のプロジェクトにGitHub Appsをインストール
- GitHub OAuth組織とGitHub Apps組織を両方作成して、任意のプロジェクトをそれぞれで利用（または両方からアクセス。この場合、ユーザー課金がそれぞれの組織に対して発生するので運用方法にご注意ください）
CircleCIの操作画面にて、簡単にGitHub Appsをインストールする方法を紹介します。
（GitHub Marketplace からCircleCIを登録する方法ではないのでご注意ください。）
GitHub Apps をインストールするとできること・できないこと
GitHub Apps をインストールするとできること
柔軟なトリガーシステムを可能にする主要な3つの機能
- GitHub以外のイベントトリガー
- Webhookを使用して、サードパーティシステム（CRM、Datadog等）からパイプラインを起動
- 新しいGitHubイベントに対応: PRのオープン、クローズ、ラベル追加、ドラフトからの変更など、より細かいイベントに対応
これにより、必要な時だけビルドを実行するため、無駄な処理を削減できるコスト削減の効果が期待できます。
2. マルチパイプラインプロジェクト
- 設定ファイルの分割: つまり、1つのプロジェクトに対して複数のConfig設定ファイルを設定できます！冗長化した巨大な単一のConfig.ymlファイルを、管理しやすい複数のファイルに分割することが可能です。
- 独立した処理: ビルド・テスト・デプロイとは別に、クリーンアップやその他の自動化タスクを独立して管理
UIから個別実行: ドロップダウンから必要なパイプラインを選択して実行
- マルチリポジトリプロジェクト
- 設定の一元管理: プラットフォームチームが複数のマイクロサービスの設定を1箇所で管理
- 中央集権的なConfig設定ファイルの設定とOverrides ：プラットフォームチームが中央集約的な設定テンプレートを管理し、開発チームが特定のジョブ部分をカスタマイズ可能。
- URL orbs：URL orbsを使用してチーム固有の設定を上書きできる機能を提供します。
- リポジトリ間のトリガー：異なるリポジトリ間でのイベント連携によるビルド実行（リポジトリをまたいでConfig設定ファイルを参照できる）
- 共有テストスイート: テストコードを独立したリポジトリで管理し、複数のアプリケーションで再利用
- 依存関係の自動テスト: ライブラリ更新時に、依存するすべてのリポジトリを自動的にテスト
-
Custom webhooks：外部システムからのwebhookやcurlリクエストによるパイプライン実行を可能にします
-
Chunk（CircleCI の自律型AIエージェント）：フレーキーテストの検出・修正、ビルドの失敗を自動診断・修復、パイプライン最適化を行います。
-
専用のロールバックパイプライン：デプロイメント専用のロールバック機能を提供。（DB，スキーマまわりの変更など、単純に前のバージョンを適用しても直らないケースがあります。お客様が設定したデプロイの設定に合わせてロールバックも設定できます。）
上記以外にも、新機能を順次追加中です。
GitHub Apps ではできないこと
GitHub Apps の組織またはパイプラインでは、現在対応していない機能があります。
対応していない機能については、順次対応を進めております。
詳しくはこちらのページをご覧ください。
GitHub Apps をインストールする方法① - 初めてCircleCIを利用する場合
初めてCircleCIを利用する方は、デフォルトの設定がGitHub Appsの組織になっています。
詳しい手順は、新規登録方法が書かれているこちらの記事をご参照ください。
GitHub Apps をインストールする方法② - 既にGitHub OAuth組織で利用している場合
GitHub Apps関連の機能を使いたいプロジェクトのページに移動します。
さらに、Project Settingsのページに移動します。
Pipelinesのタブをクリックします。
すでにGitHub OAuthのPipelineが設定されています。GitHub Appsの機能をつかうために、[Add Pileline]をクリックします。
GitHub Appsをインストールします。GitHub上の認証画面に遷移するので、認証を完了させます。
（写真アイコンの猫の名前は、Atty（アッティ―）です。もふレベル5000で、鳴き声が子猫みたいに可愛いです。）
CircleCIのアクセス権限がすべてのプロジェクト対象か、個別かを選択します。
GitHub Apps のインストールが完了すると、下記のような表示になります。
また、Name（パイプライン名）、参照する Config.ymlファイル名、Checkout Source をそれぞれ設定します。
これで、GitHub Appsのパイプラインを設定完了しました。
GitHub Apps で柔軟な Trigger を設定する方法
トリガー（Trigger）を設定します。この設定により、特定の条件が満たされたときに自動的にビルドやテストを実行します。
すでにGitHub OAuthのトリガーが設定されていますが、デフォルトの設定どおり、トリガーの設定内容は [All Pushes]となっています。
[Add Trigger]をクリックして、新しく Trigger を作成します。
[Trigger type]が GitHub App になっていることを確認して、[Next] をクリックします。
遷移先のページで、[Trigger Name]を入力します。
また、[Repository]欄で対象となるレポジトリを選択します。
Pipelineは、先ほど作成した[Test]というGitHub Apps用のパイプラインが選択されています。
次に、Triggerするタイミング（実行するタイミング）を選択します。
現在対応している項目は下記のとおりです。
| 項目 | 内容 |
|---|---|
| All pushes | すべてのプッシュ |
| Tag pushes | タグのプッシュ |
| Pushes to default branch | デフォルトブランチへのプッシュ |
| PR opened or pushed to, default branch and tag pushes | PRの作成またはPRへのプッシュ、デフォルトブランチとタグのプッシュ |
| PR opened | PRの作成 |
| Tag merged | タグのマージ |
| Tag marked ready to review | レビュー準備完了としてマークされたタグ |
| "run-ci" label added to PR | PRに"run-ci"ラベルが追加された時 |
| Pushes to open non-draft PRs | オープンかつドラフトではないPRへのプッシュ |
次に、Config branch を設定します。
"This is the branch of chisatoygc/test that will be used to fetch your config file. You must configure this because your trigger event source repo is different from your config source repo."
日本語訳：「これは、設定ファイルを取得するために使用される chisatoygc/test のブランチです。トリガーイベントのソースリポジトリが設定ソースリポジトリと異なるため、これを設定する必要があります。」
そして、Checkout branch を設定します。
"This is the branch of chisatoygc/test that will be used to checkout your code when using the checkout step. You must configure this because your trigger event source repo is different from your checkout source repo."
日本語訳：「これは、checkout step を使用する際にコードをチェックアウトするために使用される chisatoygc/test のブランチです。トリガーイベントのソースリポジトリがチェックアウトソースリポジトリと異なるため、これを設定する必要があります」
今回は、デフォルトブランチへのプッシュ時のみビルドが実行される設定にしました。
Triggersのページに、まだデフォルト設定のGitHub OAuthのTriggerがあるので、こちらを削除します。
これにより、デフォルトブランチへのプッシュ時のみビルドが実行される設定にすることができました。
GitHub OAuth の Trigger のところにあるペンのマークをクリックすれば、一度設定したTriggerを編集することができます。
まとめ
現在、Triggerの設定はプロジェクトごとのみ対応しています。早く組織全体のプロジェクトをまるっと設定できるようになってほしいですね。
このブログを書くにあたり、弊社 Field Engineer の Junho さんにアドバイスいただきました。
ネイティブ顔負けの日本語力と、こちらの知識レベルや思考パターンを考慮した説明に痺れました。ありがとうございました。
おまけ
最後に、美しい木々と、ヤマトタマムシの御姿をご覧ください。神々しいです。
（虫が苦手な方はご注意ください。）
自然の偉大さに感謝しながら、このブログを終えたいと思います。
最後まで読んでくださった方、ありがとうございました。
サポートセンター（困ったことがあったら、無料でチケットを提出して、技術的な質問ができます。） CircleCIのイベント情報
Discussion