GitHub Actionsを試す時に知っておきたいこと

## はじめに
GitHub Actionsに入門する際、知っとくといい最低限の内容をまとめてみた。

## GitHub Actionsとは
GitHubだけでCI/CD的な機能を実現するもの。
CI/CDの処理は、GitHubが提供するサーバー上の仮想マシン内で実行できるため、ユーザーが独自にサーバーを準備する必要はない。

## CI/CDとは
CIはContinuous Integration(継続的インテグレーション)のことで、ソフトウェアのビルドやテストを自動化して頻繁に実行することでソフトウェアの品質向上や開発効率化を目指す手法。
CDはContinuous Delivery(継続的デリバリー)のことで、CIに加えてリリースやデプロイまでも自動化する手法。
CI/CDは、基本的にはGitなどのバージョン管理システムと組み合わせての利用が前提となっている。
たとえば、多くのCI/CDツールではリポジトリへのプッシュやマージ、プルリクエストなどをトリガーにしている。

## ワークフロー作成の方法
ワークフローの作成は以下の二つの方法で行えそう
- GitHub Actions関連の設定は、リポジトリの「Actions」タブから行う
![スクリーンショット 2020-06-17 1.48.51.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140790/674a06aa-cc08-542d-8d44-d2f2558bb0a6.png)


- リポジトリのルートディレクトリ直下にある`.github/workflows`ディレクトリ内にYAML形式のファイルに記述することでワークフローを定義する

## ワークフローファイルの中身
下記では最低限のワークフローファイルの書き方を説明する。
詳しいファイルの書き方は[Workflow syntax for GitHub Actions](https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions)を参照する。

### ワークフローを起動するトリガーの指定(on要素)
- ワークフローを起動するトリガーとなるイベント、もしくはワークフローを起動する時刻を記述するもの
  - リポジトリへのプッシュが行われた際にワークフローを起動したい場合、次のように「push」を指定する。

    ```
    on: push
    ```

- ここで指定できるイベントは[Events that trigger workflows](https://help.github.com/en/actions/reference/events-that-trigger-workflows)に記載されている

- 特定のイベントではなく、決まった日、時刻にワークフローを実行させたい場合は、「on.schedule」要素で日時の指定を行う。

    ```
    on:
      schedule:
        - cron: '30 * * * *'
    ```

### ワークフローを実行する仮想マシン環境の指定(runs-on要素)
- ワークフローを実行する仮想マシン環境を指定する
- 「GitHubホストランナー」と「セルフホストランナー」のいずれかを設定する

#### GitHubホストランナー
- GitHubがあらかじめ用意している実行環境でワークフローを実行する
  - たとえばUbuntu 18.04環境でワークフローを実行したい場合は下記のようにする

    ```
    runs-on: ubuntu-18.04
    ```
- 2020/06/17時点で利用可能なものは下記([GitHub Actionsのワークフロー構文](https://help.github.com/ja/actions/reference/workflow-syntax-for-github-actions)より)

![スクリーンショット 2020-06-17 2.11.05.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140790/bf6e0d1b-2d4e-f81a-f494-40a17583ed8a.png)

#### セルフホストランナー
- ユーザーが独自に用意した実行環境でワークフローを実行する
- 詳しくは[About self-hosted runners](https://help.github.com/ja/actions/hosting-your-own-runners/about-self-hosted-runners#requirements-for-self-hosted-runner-machines) を参照



## 実行する処理を記述する(jobs要素)
- 1つのワークフロー実行は、1つ以上のジョブからなる
- それぞれのジョブは`runs-on`で指定された環境で実行される

### jobs内の要素
- job id
  - ジョブを参照する際などに使われる一意な文字列
- job name
  - 管理画面などに表示される名前として使われる文字列
- steps
  - 各ジョブで実行する処理を記述するオブジェクトのリスト
  - stepの「name」
      - 処理内容を示す名前
  - stepの「run」
      - （シェル経由で)実行するコマンドを指定

```
jobs:
  <job id>:
    name: <job name>
    steps:
      - name: <step name1>
        run:
      - name: <step name2>
        run:
```
- uses
  - steps以下ではrun要素ではなくuses要素を指定することで、任意のActionを実行したり、指定したDockerコンテナを起動してその中で指定した処理を実行したりできる。

### 逐次的なジョブの実行
デフォルトでは、ジョブは並行して実行される。 
ジョブを逐次的に実行するには、`jobs.<job_id>.needs`などとして他のジョブに対する依存関係を定義

```
jobs:
  job1:
  job2:
    needs: job1
  job3:
    needs: [job1, job2]
```


## 秘匿情報などはSECRETで管理する
GitHub Actionsでは、リポジトリやワークフロー設定ファイル中に認証情報などの秘密情報を格納することは避けるべきだとされている。
そういった秘密情報をワークフロー内で扱いたい場合、「encrypted secrets」という仕組みを利用する。

#### encrypted secrets
encrypted secretsは、事前にリポジトリの設定画面から秘密情報（「secret」）を登録しておくことで、この情報に安全にアクセスするための手段を提供する仕組みである。
登録した秘密情報は、ワークフロー設定ファイル内からはコンテキスト（「{{ Secrets.＜名前＞ }}」）を使って参照できる。

#### encrypted secretsの利用
encrypted secretsを利用するには、まずリポジトリの設定画面内の「Secrets」から使用したい情報を登録する。 
なお、一度入力した情報はその後は閲覧・編集できないので注意。 
対応する値を変更したい場合は、一度削除してもう一度同じ「Name」を指定して再作成する。 
登録できるデータは最大64KBまでという制約がある。それ以上のデータを登録したい場合は、ファイルを暗号化してリポジトリ内に格納しておき、それを復号するためのキーをSecrets経由で与えてワークフロー内で復号する、という手法がある。 
詳しくはドキュメントの[Creating and storing encrypted secrets](https://docs.github.com/en/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets)に書かれている。


## 最後に
ソースコードのバージョン管理に多くの人が用いているであろうGitHubで容易にCI/CD導入ができてしまうのは、非常にありがたいことである。




## 参考
- [GitHub Actions Documentation](https://docs.github.com/en/actions)
- [GitHubの新機能「GitHub Actions」で試すCI/CD](https://knowledge.sakura.ad.jp/23478/
)