GitHub Actions使ってみた

## GitHubActionsとは？

公式ドキュメント：
https://help.github.com/ja/actions

- リポジトリ内で何かしらのイベントが発生したときにワークフローを実行できる仕組み
- CI/CDをメインとし、それ以外にもGitHubの様々なイベントにフックして自動で処理を実行できる
    - issueが登録されたときに担当者を自動で割り当てたり、PRが作成されたときに Slack に通知を飛ばしたり など
- 何が嬉しいの？→GitHub内でイベントが完結できる！
- 注意）2019年8月に大幅改定となったため、それ以前の記事は若干古いものもあるかも

## 料金
https://github.co.jp/features/actions
https://help.github.com/ja/github/setting-up-and-managing-billing-and-payments-on-github/about-billing-for-github-actions

- Publicリポジトリは完全無料
- PrivateリポジトリはGitHubのプランにより
    - 従量課金制
    - ビルド時間は毎月リセット
    - ストレージ容量およびジョブ実行時間上限については、追加で利用料金を支払うことで上限を超えた利用が可能。
    - 月あたりの上限金額を設定できるようになっていて、デフォルトでは0ドルに設定されているため、これを変更しない限りは勝手に料金支払いが発生することはない。


## 使い方
GitHub Actionsでワークフローを設定する

**ワークフローとは？**
リポジトリ内でのなにかしらのやりたいことを自動化したもの
一つ以上の複数のジョブから構成

### ワークフローファイル
- フォルダは固定で`.github/workflows/`
- ファイル名はなんでも良い。
- YAML形式で記述して、`.yml`または`.yaml`で保存
- 設定ファイルは複数作成することも可能
- リポジトリの`Actions`タブから`Set up workflow yourself`で作成することも可能

### ワークフローを実行させるイベント
https://help.github.com/ja/actions/reference/events-that-trigger-workflows

1. GitHubイベントで実行させる方法
    - 例) pushやpull_requestなど
2.  cron 形式で記述して定期実行
    - 例） 15分ごとにワークフローを実行など
3.  外部からワークフローを実行
    - 例）GitHubが用意しているエンドポイントにcurlでリクエストを投げて実行
    - [REST API エンドポイント](https://developer.github.com/v3/repos/#create-a-repository-dispatch-event)

### ワークフロー設定ファイルの構文
https://help.github.com/ja/actions/reference/workflow-syntax-for-github-actions

Hello Worldを表示するワークフロー
https://github.com/mkato7914/hello_world/actions/runs/59640165/workflow

```.github/workflows/rails.yml
name: Hello, World!
on: push

jobs:
  build:
    name: Greeting
    runs-on: ubuntu-latest
    steps:
      - run: echo "Hello, World!"
```

**name**
省略可能
ワークフローの名前、省略された場合はワークフローファイルへの相対パス

**on**
必須
実行したいイベントの定義、複数設定可能
サンプルではpushを指定しているので、githubにpushされるごとにワークフローが実行される

複数指定したい場合の書き方

```yml
# プッシュあるいはプルリクエストでワークフローをトリガー
on: [push, pull_request]
```

タグやブランチに対してイベントのフィルタも可能

```yml
# masterブランチに対してのみ行いたい場合
on:
 push:
  branches:
    - master
```

**jobs**
必須
このブロック内でワークフローを定義

**ジョブとは？**
ワークフローの中のタスク
並列実行や、ジョブAが成功したらジョブBを実行というように依存関係ももてる

**build**
必須
ジョブのIDの定義。今回はbuildとしたが重複しないキーであればなんでもいい。
使える文字列はアルファベット、数字、-、_

**name**
省略するとジョブIDが表示される
ジョブの名前。
ブラウザ上で Actions タブを開いたときに表示

**runs-on**
必須
ワークフローが実行される仮想環境
GitHub が提供する VM(仮想マシン)環境と、ユーザーが構築した独自の環境が使える
Linux、Windows、macOS

**steps**
必須
ジョブが実行するステップの定義
それぞれのステップは、それぞれ異なるプロセスで実行される。
ステップ内で環境変数を変更しても、後のステップには変更が反映されない

**ステップとは?**
なにかしらのコマンドの実行か、なにかしらのアクションの呼び出しを行う。

**アクションとは？**
GitHub Actions が提供する、なにかしらの処理の固まりを表す単位。公開したり共有したりすることが可能で、ステップの中で呼び出される。
アクションは自作することもできるし、コミュニティで共有されたアクションを利用することも可能。（後述）


### 秘密情報
ワークフロー内で秘密情報を扱いたい場合
リポジトリを開き、`Settings` → `Secrets` → `Add a new secret`で登録が可能
保存した秘密情報は、GitHub Actions 以外では使われない
最大で 100 個まで
ログは自動でマスクされるが、複雑な情報はマスクの仕組みが正常に働かないこともあるそう。。。

```yaml

# 秘密情報の書き方
steps:
- run: echo "${{ secrets.SECRET_TOKEN }}"
```

### バッジ機能
リポジトリの`Actions`タブからワークフローを開くと、`Create status badge` のところから、バッジを表示するための markdown がコピーできる。
README.md に埋め込むとバッジが表示される。

<img width="1039" alt="スクリーンショット 2020-03-26 11.43.52.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/129882/9b6bbf18-5acd-d8af-4a8f-41301effb8ad.png">


### キャッシュ
- 異なるビルド間でダウンロードしたパッケージを使いまわして高速化することができる
- キャッシュが保存されるのはジョブ成功時のみで、ジョブが失敗・キャンセルされた場合はキャッシュが保存されない
- キャッシュが利用できるイベントタイプは`push`と`pull_request`
- GitHub が公式で提供している、ワークフロー実行中にキャッシュを扱うためのアクション
    - https://github.com/actions/cache
    - プログラミング言語ごとの例
        - https://github.com/actions/cache/blob/master/examples.md

### 制限事項
- リポジトリごとに同時実行できるワークフローの数は最大で 20 まで
- ワークフロー内の各ジョブの実行時間は最大で 6 時間まで
- アカウントごとに全リポジトリで同時実行できるジョブの数はプランによって
異なる
– 無料プラン: 20(macOS ジョブは 5)
– Pro: 40(macOS ジョブは 5)
– Team: 60(macOS ジョブは 5)
– Enterprise: 180(macOS ジョブは 15)


## アクションについて
https://help.github.com/ja/actions/building-actions/about-actions

GitHub公式のアクション
https://github.com/actions

GitHub Marketplace
https://github.com/marketplace

- アクションという単位で実行可能なタスクを作成できる（pulginみたいなもの）
- 自作したアクションは`.github/actions`ディレクトリ下にアクションごとにディレクトリを作成して保存することが推奨されている
- 作ったアクションはGitHub Marketplace へ公開できる
- アクションはJavaScriptまたはDockerコンテナで作成ができる

## サンプルワークフロー
### RailsでCIを回して完了後slackに通知を投げる
https://github.com/mkato7914/github_action_test/actions

#### slackの設定
公開されているアクションを使う
https://github.com/marketplace/actions/slack-notify

#### Railsの設定
こちらの記事を参考にさせていただきました
https://qiita.com/DaichiSaito/items/f0a79f3eac04f1034a30


## 参考リンク
- https://www.kaizenprogrammer.com/entry/2020/02/27/093740
- https://knowledge.sakura.ad.jp/23478/
- https://qiita.com/DaichiSaito/items/f0a79f3eac04f1034a30

## 備考

### CI/CDとは？
#### CI: Continuous Integration
継続的インテグレーション
リポジトリに変更を行い、そのたびにテストを含む自動ビルドが毎回実行されるようにすること。
目的：問題を早期発見できるように高速なフィードバックをシステム化すること

#### CD: Continuous Deployment or Continuous Delivery
継続的デプロイメント または 継続的デリバリー
CI をさらに発展させたもの
コードが変更されるたびに自動でテストなどが実行されるのは CI と 同じです。CD では、さらにソフトウェアがいつでもリリースできる状態で あるところまで毎回保証できるようにします。