GitHub Actionsを導入する際に確認しておくこと
はじめに
この記事は、GitHub Actionsを新規導入する際に、事前にチーム内で確認・共有しておくべき基本的な事項をまとめたものです。筆者の経験や周囲のチームでのユースケースを元にしていますが、基本的にはどのようなチームでも参考になる内容になっているつもりです。
なお、この記事ではCI/CDの基本、ワークフローの書き方やHowto/Tipsといった具体的な利用方法については扱っていません。これらについては他にも多くの有用な記事が存在しますので、そちらをご覧ください。
また、この記事はGitHub Teamsでの利用を想定した内容で記述しています。（Enterpriseなどの）他のプランでは仕様が異なる場合があるのでご注意ください。
記事の内容は正確さを心がけていますが、ご自身でも内容の確認をお願いいたします。
料金
GitHub Actionsはpublic repositoryでの利用は無料です。ただし、一般的な企業でpublicリポジトリでプロダクトやサービスのコードを管理しているケースは限られていると思いますので、あくまで参考程度に覚えておくと良いでしょう。基本的にはprivate repositoryでの料金システムを把握すればOKです。
private repositoryでの利用は有料ですが、GitHubの各プランに応じて一定量の無料枠が用意されています、以下の表はプランとそれに含まれるストレージと利用時間の無料枠です。
表を見るとGitHub Teamではストレージが2GB、利用時間が3,000分/月であることが分かります。
GitHub ActionsではCI/CDを実行する環境（VMホスト）としてGitHubが用意したホストマシンが利用できます、これをGitHubホステッドランナーと呼びます。利用時間とはこのGitHubホステッドランナーでテストやビルドを実行した時間のことを指します。
なお、利用時間に含まれないセルフホステッドランナーという仕組みもありますがここでは割愛します。ランナーの種類によっては無料枠では利用できないものもありますがこちらも詳細は割愛します。
3,000分/月の表記から分かる通り、利用時間の無料枠は毎月リセットされます。そのため毎月の利用時間が無料枠の範囲に収まるのであれば課金が発生することなく利用することが可能です。
注意点として、無料枠の利用時間はランナーのOSの種類に応じて係数が決まっており、macOSランナーはLinuxに対して10倍の利用時間として換算されます、つまりmacOSを利用する場合は無料枠の 1/10 が実際に利用可能な時間になります（3,000分なら300分）。
なお、係数が適用されるのは無料枠における利用時間を算出する場合のみです。後述の従量課金での利用時間の算出には適用されません。
ストレージはCI/CDのジョブで成果物など保存する際に利用することができます。こちらは利用時間とは異なり実際に使用中の容量をもとに計算されるので注意が必要です。自動ローテーションを利用したり、必要に応じて個別に削除する必要があります。
新たにGitHub Actionsを導入する場合、まずは自分たちがCI/CDで実行・処理する内容がこの無料枠の範囲に収まるのか試算すると良いでしょう。ただし、ここで試算するポイントは「仮に無料枠を超えて利用が必要になった場合にどうすれば良いか」をあらかじめ確認しておくためです。
なぜなら、企業での利用においては無料で利用できることは良いとして、必要なときにはお金を払ってでも確実に利用できることの方が重要だからです。仮に無料枠を超えそうになった、もしくは超えたときにCI/CDが利用できないといった状態になってしまうと、それが原因で業務が止まり、テストやリリースができない状況に陥りかねません。
GitHub Actionsでの無料枠を超える使用は使用制限によって制御されます。使用制限は課金が発生した場合に許可する課金額の上限を設定するもので、デフォルトでは使用限度額として0ドルが設定されています。つまり、デフォルトでは無料枠を超えることはありません、言い換えると無料枠を超えて使用することもできません。
筆者が普段利用しているアカウントではデフォルトで $0.00 が利用上限（spending limit）として設定されていました、つまり無料枠を超えた利用はできない状態です。こちらはSettingsのBillingから確認することができます。
なお、使用制限のデフォルトは支払い方法などによって異なるようなので、必ずご自身のアカウントの設定を確認してください。下記のリンク先に確認方法が記載されています。
また、無料枠を超えた課金はプラン（アカウント）が年払いの場合でも月単位での請求となります。
無料枠を超えた場合の対応が確認できたところで、では実際に「何をどれくらい使ったらいくら課金されるのか」を確認します。GitHubホステッドランナーの料金はOSの種類とスペックによって分かれています、表はこちらになります。
2024.6時点で最も安いのはarm64 Linux 2-coreのタイプで $0.005/分 です、約0.78円といったところですね。
一方、macOSの場合は最も安いタイプ（3 or 4 core M1 or Intel)でも $0.08/分 なので最安のLinuxと比べて10倍以上の差があります。基本的にはCI/CDのワークフローの用途に合わせて最適なOSとスペックを選択することになります。
導入検討の際には無料枠の仕組みを押さえつつ、従量課金へ移行する際の仕様などを確認しておくことで安心して利用を開始することができるでしょう。
Runner
GitHub ActionsではCI/CDを実行するVMホストのことをRunnerと呼んでいます、Runnerには２種類ありGitHubが提供するRunnerのことをGitHubホステッドランナーと呼びます。もう一つはセルフホステッドランナーと呼び、こちらはユーザー側で用意したホストマシンを利用するタイプです。
料金の中でも説明しましたが、GitHubホステッドランナーは有料（無料枠あり）ですが、セルフホステッドランナーの利用は無料です。ただしセルフホステッドランナーは自分でマシン（インスタンス）を用意する必要があります。セルフホステッドランナーはCI/CDの要件が特殊だったり大規模に利用されるケースでの利用を想定しているので今回は割愛します。
GitHubホステッドランナーはリポジトリの種類（public or private）と課金の有無（無料枠 or 従量課金）によって種類が分かれています。例えばprivate repositoryの無料枠で利用できるGitHubホステッドランナーの一覧はこちらになります。
前述した料金の章で利用上限（spending limit）の話がありましたが、課金を有効にするとより性能の良いRunnerを利用することも可能になります。
Runnerのスペックは先ほどの通りですが、Runnerは予め開発に必要なツールなどがインストールされた状態で提供されます。ツールのバージョンなどを含むRunnerの構成はGitHub上に公開されています。
インストールされていないツールを使いたければ、CI/CDのワークフローの中でインストールすることも可能です。
導入検討の際には、自分が必要とするRunnerが提供されていること、Runnerの構成、使用するRunnerの料金が幾らなのかを予め確認しておくと良いでしょう。
セキュリティ
CI/CDサービスを利用する際にはセキュリティを考慮する必要があります、誤った使い方をすると秘匿情報の漏洩などにつながる恐れがあるためです。セキュリティを取り上げるとそれだけでも一つの記事が書けそうなので、ここでは主な情報源の紹介にとどめます。
公式ドキュメントでもセキュリティは重要なトピックとして扱われています、まずはこちらの内容に必ず目を通しておきましょう。
その上で、実際のシーンでは実践的な内容（HowTo,Tipsなど）も必要になるため、以下のような記事を参考にすると良いでしょう。
GitHub Teamsでは主にprivate repositoryでの利用が中心になるかと思います、その場合は第三者がrepositoryを閲覧・編集することができないため幾分かはリスクが低減します。その場合でもサードパーティーのアクションを通じたセキュリティ侵害などの恐れは依然として生じるためリスク管理は必要です
見落としがちなポイントとしてWorkflow permissionsのデフォルト値がリポジトリを作成した時期によって異なります。古いリポジトリではRead and write permissionsが選択されていて、Allow GitHub Actions to create and approve pull requestsが有効になっているので手元のリポジトリの設定をチェックすると良いでしょう。
導入検討の際には、公式ドキュメントや記事などの情報を参考に、適用するルールやプラクティスをチーム・組織で定めておくことをお勧めします。
OIDC
IAMに紐づくアクセスキーなどは漏洩時のリスクが大きいため、GitHub ActionsからAWSなどのクラウドサービスへアクセスするケースではOIDCを積極的に使いましょう。
ログ
デフォルトではワークフローの実行ログと成果物（Arfitacts）は90日まで保存されます、保存期間が過ぎたものは自動的に削除されます
プライベートのリポジトリの場合は保持期間を1から400日の間で変更できます。
組織の情報統制などの観点で長期間のログの保存が必要な場合は保存期間を延ばすことを検討しましょう。
注意点としてログと成果物の保存期間を分けることはできないので、ログのみを長期間保存したいようなケースではワークフロー内で成果物の保存期間を別途指定するなどの工夫が必要になることがあります（ストレージを圧迫するため）。成果物の保存期間を指定する方法はこちらにサンプルコードがあります。
承認機能
信頼しているチーム内での利用においてもGitHub Actionsを通じてデプロイなどの自動化を行う際には、実行の際にレビュー（承認）を必須としたいケースもあります。
そのようなケースではEnvironmentsの利用を検討しましょう。
HowToに近い内容ではありますがデプロイを管理する際に役に立つ機能の一つとして覚えておくと良いと思います。
さいごに
GitHub ActionsはGitHubとの連携が強力で、正しく利用すればとても便利なサービスです。導入検討の際にはこの記事に記載されていることについてチーム内で認識のすり合わせなどを行い、スムーズな導入を目指しましょう。
Discussion