【GitHub Actions】ビルドとテストの自動化を整理する

# 背景・目的
GitHub Actionsの[ビルドとテストの自動化](https://docs.github.com/ja/actions/automating-builds-and-tests)を元に整理します。

# まとめ
- GitHub Actionsの継続的インテグレーションでは、リポジトリのコードをビルドしてテストを実行できます。
- GitHub Actionsのランナーは、GitHub Actions ワークフローでジョブを実行するマシンです。

# 概要
## 継続的インテグレーションについて
[継続的インテグレーションについて](https://docs.github.com/ja/actions/automating-builds-and-tests/about-continuous-integration)を元に整理します。

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

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

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

- CIでは、ビルドとテストを継続的に行う
- テストでは、下記を行う
    - コードの文法チェック
    - セキュリティチェック
    - コードカバレッジ
    - 機能テスト
    - カスタムチェック

### GitHub Actionsを使用する継続的インテグレーションについて
> GitHub Actions を利用した CI では、リポジトリ中のコードをビルドしてテストを実行できるワークフローが利用できます。 ワークフローはGitHubホストの仮想マシン、もしくはあなたが自分でホストするマシン上で実行できます。 

- GitHub Actionsでは、コードをビルド＆テストを実行できるワークフローが利用できる
- ワークフローはGitHubホストの仮想マシン、もしくはあなたが自分でホストするマシン上で実行できる。

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

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

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

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



## GitHub ホステッド ランナーの使用
> GitHub では、ワークフローを実行するためのホストされた仮想マシンを提供します。 仮想マシンには、GitHub Actions で使用できるツール、パッケージ、および設定の環境が含まれています。

### GitHub ホステッド ランナーの概要
#### 概要
> ランナーは、GitHub Actions ワークフローでジョブを実行するマシンです。 たとえば、ランナーはリポジトリをローカルにクローンし、テスト ソフトウェアをインストールしてから、コードを評価するコマンドを実行できます。

> GitHub は、ジョブの実行に使用できるランナーを提供します。または、独自のランナーをホストすることもできます。 各 GitHub ホステッド ランナーは、ランナー アプリケーションとその他のツールがプレインストールされた GitHub によってホストされる新しい仮想マシン (VM) であり、Ubuntu Linux、Windows、または macOS オペレーティング システムで使用できます。 GitHubホストランナーを使用すると、マシンのメンテナンスとアップグレードが自動的に行われます。

- GitHub Actionsワークフローでジョブを実行する仮想マシン
- 仮想マシンには、Linux、Windows、mac OSが使用できる。
- ランナーでは、下記が実行できる。
    - リポジトリをローカルにクローン
    - テスト
    - ソフトウェアをインストール
    - コードを評価

#### GitHub ホステッド ランナーの使用
> GitHub ホステッド ランナーを使用するには、ジョブを作成し、runs-on を使用してジョブを処理するランナーの種類を指定します (例: ubuntu-latest、windows-latest、または macos-latest)。 ランナーの種類の完全な一覧については、「GitHub ホステッド ランナーの使用」を参照してください。リポジトリに repo: write アクセス許可を持っている場合は、リポジトリ内のワークフローで使用できるランナーの一覧を表示できます。 詳細については、「リポジトリの使用可能なランナーを表示する」を参照してください。

>ジョブが開始されると、GitHub によって、そのジョブの新しい VM が自動的にプロビジョニングされます。 ジョブ中のすべてのステップは VM で実行されるため、ランナーのファイルシステムを使用して、そのジョブにおけるステップで情報を共有することができます。 ワークフローは、VM で直接実行することも、Docker コンテナーで実行することもできます。 ジョブが完了すると、VM は自動的に使用停止になります。

>次のダイアグラムは、2 つの異なる GitHub ホステッド ランナーでワークフロー内の 2 つのジョブがどのように実行されるかを示しています。
    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/206276/3a6107a7-41fd-09d5-8129-b49f2e959b00.png" width=500>


[※ 出典：GitHub ホステッド ランナーの使用](https://docs.github.com/ja/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners)

- runs-on:で、VMを指定する。
    - ubuntu-latest
    - windows-latest

#### GitHub ホステッド ランナーによって使用されるクラウド ホスト
> GitHub は、Microsoft Azure の Standard_DS2_v2 仮想マシン上で GitHub Actions ランナー アプリケーションがインストールされた Linux および Windows ランナーをホストします。 GitHubホストランナーアプリケーションは、Azure Pipelines Agentのフォークです。 インバウンドのICMPパケットはすべてのAzure仮想マシンでブロックされるので、pingやtracerouteコマンドは動作しないでしょう。 Standard_DS2_v2 リソースについて詳しくは、Microsoft Azure ドキュメントの「Dv2 および DSv2 シリーズ」をご覧ください。 GitHub は、Azure データ センターで macOS ランナーをホストします。

- GitHub は、Azureの仮想マシン上で動作します。

#### ワークフローの継続性
> GitHub Actionsサービスが一時的に利用できなくなっている場合、ワークフローの実行はトリガーされてから30分以内にキューイングされていなければ、破棄されます。 たとえば、ワークフローがトリガーされ、そしてGitHub Actionsサービスが31分以上利用できなければ、そのワークフローの実行は処理されません。
> さらに、ワークフロー実行が正常にキューに入れられても、45 分以内に GitHub ホステッド ランナーによって処理されない場合、キューのワークフロー実行は破棄されます。

- 30分以内にキューイングされていない場合、実行されない
- キューイング後、45分以内に実行されない場合、破棄される。

#### 管理者特権
> Linux と macOS のどちらの仮想マシンでも、パスワードレスの sudo が実行されます。 現在のユーザーより高い特権が必要なコマンドやインストール ツールを実行する必要がある場合は、パスワードを入力する必要なく、sudo を使うことができます。 詳しくは、Sudo のマニュアルをご覧ください。

- sudoが使われる

#### IP アドレス
> GitHub Actions で GitHub ホステッド ランナーに使われる IP アドレス範囲のリストを取得するには、GitHub REST API を使用できます。 詳しくは、「Meta」エンドポイントの応答で actions キーをご覧ください。

- Github REST APIによりランナーで使用されるIPアドレスの範囲が取得できる。


# 実践
## リポジトリで使用可能なランナーの表示
1. Githubのリポジトリを表示し、「Actionss」タブをクリックします。
1. ナビゲーションペインで、Runnersをクリックします。
    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/206276/2105bfb3-5bf1-8dd1-a4db-d5f67f4a290f.png" width=300>

1. 使用可能なランナーが表示されました。
    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/206276/fb9be270-503f-a9e9-7acf-80068924583c.png" width=500>


# 参考
https://docs.github.com/ja/actions/automating-builds-and-tests

https://qiita.com/zumax/items/df1f36b96ee819cfb25e