はじめてのGitHub Actions

# 前置き
この記事は[GitHub Actions Advent Calender 2020](https://qiita.com/advent-calendar/2020/github-actions)の20日目の記事です。昨日は[@taptappun](https://qiita.com/taptappun)さんの記事でした。

# 概要
GitHub Actions誕生までの歴史、GitHub Actionsの用語や環境について記載しています。GitHub Actionsにはクラウド版とオンプレミス版がありますが、この記事ではオンプレミス版の説明は省きます。
間違っている箇所がある場合はご指摘をお願いします。

# GitHub Actionsとは
GitHubの公式ドキュメントから抜粋します。
> GitHub Actionsは、コードを保存するのと同じ場所でソフトウェア開発のワークフローを自動化し、プルリクエストやIssueで協力することを支援します。 個々のタスクを書き、アクションを呼び出し、それらを組み合わせてカスタムのワークフローを作成できます。 GitHub Actions では、エンドツーエンドの継続的インテグレーション (CI) と継続的デプロイメント (CD) 機能をリポジトリに直接ビルドすることができます。

[Using GitHub Packages with GitHub Actions](https://docs.github.com/ja/free-pro-team@latest/packages/using-github-packages-with-your-projects-ecosystem/using-github-packages-with-github-actions)

この文章をまとめると、GitHub ActionsはGitHubに備わっているPull RequestやIssueなどの機能をトリガーにして、ビルド、テスト、デプロイなどをワークフローとして作成・実行できるツールとなります。

# GitHub Actions誕生までの歴史
GitHub Actionsは2018年10月16日〜17日に開催された[GitHub Universe](https://githubuniverse.com/2018/)で発表されました。また、翌年の[GitHub Universe](https://www.publickey1.jp/blog/19/github_actionsgithubcicdgithub_universe_2019.html)でGitHub Actionsが正式版となりました。この10年前の2008年4月10日にGitHubの正式版が発表されています。
そのため、GitHubが登場してからGitHub Actionsの登場までの10年間、世界とGitHubで何が起きていたか、年表に表してみることにしました。なおGitHubのイベントについては、GitHub10周年ページの翻訳サイトがあり、そこから引用しています。
[GitHubの10周年ページを簡単に翻訳してGitHubの歴史を振り返ってみた](https://findy-code.io/engineer-lab/translate_github_ten)

## 世界とGitHubの変遷
|年  |月  |世界（イベント） |GitHub（イベント） |
|---|---|---|---|
|2008  |4  |・[Google App Engineプレビュー版リリース](https://googleblog.blogspot.com/2008/04/developers-start-your-engines.html) <br> ・[MicrosoftがAzure Platform Service、Windows Azureを発表](https://cloudblogs.microsoft.com/windowsserver/2008/10/27/pdc-2008-azure-services-platform-and-windows-server/) |・GitHub β版時代にRuby on Railsが参加 <br> ・GitHub登場 |
|2009  |5  |  |・Node.js ローンチ |
|  |11  |・[DevOpsDays開幕](https://legacy.devopsdays.org/events/2009-ghent/)、DevOpsの用語が広まる  |  |
|2012  |1  |  |・JavaScriptがGitHub上でもっとも人気のある言語となる |
|2013  |1  |  |・GitHubユーザが300万人を突破 |
|  |3  |・[Docker登場](https://www.docker.com/blog/dotcloud-is-becoming-docker-inc/) |  |
|2014  |5  |・[Googleが、全ソフトウェアをコンテナ化し、毎週20億個ものコンテナを起動していると発表](https://speakerdeck.com/jbeda/containers-at-scale)  |  |
|  |6  |・[Docker 1.0リリース](https://www.docker.com/blog/announcing-docker-hub-and-official-repositories/) <br> ・[GoogleがKubernetesをOSSとして発表](https://cloudplatform.googleblog.com/2014/06/an-update-on-container-support-on-google-cloud-platform.html) |  |
|  |8  |・[VMwareがDockerと協業発表](https://www.publickey1.jp/blog/14/vmwaredockerkubernetes.html) |  |
|  |10  |・[MicrosoftがDockerと連携、Windows ServerでDocker採用と発表](https://weblogs.asp.net/scottgu/docker-and-microsoft-integrating-docker-with-windows-server-and-microsoft-azure) |・Microsoftが.NETをOSS化  |
|  |11  |・[Amazon Web ServicesがLambdaを発表](https://aws.amazon.com/jp/about-aws/events/reinvent-report-2014-pt2/)、サーバーレスが普及へ（以降Amazon Web ServicesはAWSと省略） |  |
|2015  |6  |・[Open Container Project発足、コンテナは統一仕様へ](https://www.publickey1.jp/blog/15/open_container_project.html) |  |
|  |7  |・[Kubernetesが1.0へ。Kubernetesの開発の主体が新団体「Cloud Native Computing Foundation」となる](https://cloudplatform.googleblog.com/2015/07/Kubernetes-V1-Released.html)（以降、Cloud Native Computing FoundationはCNCFと省略） |  |
|  |12  |  |・SwiftがOSSとなる  |
|2016  |3  |・[Docker for Mac/Windowsが登場](https://www.docker.com/blog/docker-for-mac-windows-beta/)  | |
|  |6  |・[Docker Engineにオーケストレーション機能が組み込まれる](https://www.docker.com/blog/docker-1-12-built-in-orchestration/) | |
|  |10 |・[Kubernetes側がcri-oを開発中と発表](https://www.publickey1.jp/blog/16/kubernetescri-odocker.html) | |
|  |12 |・[Docker Engineのコアランタイムをcontainerdとして独立させる](https://www.docker.com/docker-news-and-press/docker-extracts-and-donates-containerd-its-core-container-runtime-accelerate) |
|2017  |4  |・[Moby Projectが発表される](https://www.docker.com/blog/introducing-the-moby-project/) |  |
|  |5  |  |・NPO（非営利組織）、NGO（非政府組織）のアカウントが3万件を突破 <br> 1億回目のPull Requestがマージされる |
|  |7  |・[OCI v1.0が発表](https://www.publickey1.jp/blog/17/open_container_initiativeoci_v10.html) <br> ・[MicrosoftがCNCFへ加盟](https://www.cncf.io/announcements/2017/07/26/microsoft-joins-cloud-native-computing-foundation-platinum-member/) |  |
|  |8  |・[AWSがCNCFへ加盟](https://www.cncf.io/announcements/2017/08/09/amazon-web-services-joins-cloud-native-computing-foundation-platinum-member/) |  |
|  |9  |・[OracleがCNCFへ加盟](https://www.cncf.io/announcements/2017/09/13/oracle-joins-cloud-native-computing-foundation-platinum-member/) <br> ・[VMwareがCNCFへ加盟](https://www.cncf.io/announcements/2017/09/26/pivotal-vmware-join-cloud-native-computing-foundation-platinum-members/) |  |
|  |10  |・[DockerがKubernetesの統合とサポートを発表](https://www.docker.com/blog/kubernetes-docker-platform-and-moby-project/) <br> ・[Microsoft AzureがAzure Kubernetes Serviceを発表](https://azure.microsoft.com/en-us/blog/introducing-azure-container-service-aks-managed-kubernetes-and-azure-container-registry-geo-replication/) <br> ・[GoogleがGoogle Container EngineをGoogle Kubernetes Engineへ改名と発表](https://cloud.google.com/blog/products/gcp/introducing-certified-kubernetes-and-google-kubernetes-engine) <br> ・[cri-o 1.0リリース](https://medium.com/cri-o/cri-o-1-0-is-here-d06b97b92a98) |  |
|  |11  |・[AWSがAmazon Elastic Container Service for Kubernetesを発表](https://aws.amazon.com/jp/blogs/news/amazon-eks-now-generally-available/) |  |
|2018  |10  |・[MicrosoftがGitHubを買収](https://news.microsoft.com/announcement/microsoft-acquires-github/) | |

### 歴史から見えること
個人の考察です。
Dockerの登場、CNCFの設立、Kubernetesの登場により一気にコンテナ技術が発展してきました。またCNCFの設立により、コンテナ周りのテクノロジーが急速に増えてきました。これにより、開発者はコンテナをメインとした開発、CI/CD運用に移行していったと思われます。
また、GitHubにおいてはユーザ数が増加し、有名なプロジェクトのOSS化が行われてきました。またPull Requestによるマージが1億回を突破したことから、GitHub上でのユーザの活動が非常に活発になっていたと考えられます。

## なぜGitHub Actionsが誕生したのか
### GitHubが抱えていた問題
詳しい説明が[GitHubの新機能「GitHub Actions」でワークフローを自動化しよう](https://codezine.jp/article/detail/11450)にありましたので、一部抜粋して説明します。

> ソフトウェア開発を取り巻く環境は日々変化し、様々なツールやライブラリが次々と登場する時代がやってきました。
・・・中略・・・
> 一方で新しいツールができることや、それらを正しく連携させるための設定はどんどん複雑化し、本来の目的だったソフトウェア開発のために十分な時間を取れないといったケースが増えています。

開発を便利に楽にするためのツールが、逆に開発の時間をとられてしまうという逆転の現象が起きてしまったようですね。これらのツールがどのくらいあるのか、CNCFが作成している代表的なクラウド関連テクノロジー一覧を記事の中で紹介されていましたので、改めて確認してみました。

<img width="600" height="600" alt="" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/406773/69b85af3-7d37-2ef2-2935-e2fa02cbb52c.png">
[CNCF Cloud Native Interactive Landscape
](https://landscape.cncf.io/)※2020/12/02に取得しました。

この図を見ると、上記記事が執筆された2019年4月5日時点よりもさらにツールが増加していることが分かります。この大量のツールが登場したことによる問題を、記事では次のように伝えられています。

> ソフトウェアのソースコードを一定の品質に保ちつつ速いサイクルで開発・デプロイするために、現代ではこれだけ多様な技術が使われるようになりました。テスト、ビルド、デプロイのパターンだけでも多くの選択肢があり、その他のツールの利用も含めると組み合わせは無限にあります。苦労してプロジェクトに最適な組み合わせを見つけ、ワークフローを作り上げたとしても、今まではそれをコードとして記述するスタンダードな方法がなかったので、GitHub上で共有したり再利用することができないという問題がありました。

> GitHubの利用形態について分析すると、全ユーザの約60％がリポジトリと何らかの外部ツールやサービスを連携させている、という結果がわかっていました。そこでGitHubでは、ソフトウェア開発のプラットフォームとしてこの問題を解決し、開発者の体験をより良いものにするにはどうしたらいいか考え、2018年10月にGitHub Actionsを発表しました。

GitHub Actionsがない時代では、他プロジェクトのワークフローを参考に組み立てたいと思っても、再現させるのは一苦労だったのでしょうね。
GitHubのミッションとして
>GitHub’s mission is to help every developer—regardless of experience level—learn, code, and ship software effectively.

[A bright future for GitHub](https://github.blog/2018-06-04-github-microsoft/) 
や

> At GitHub, our mission is to build the global platform for developer collaboration

[Securing software, together](https://github.blog/2019-09-18-securing-software-together/)


を掲げられている視点から見ると、GitHub Actionsの誕生は必然だったとも思えそうです。

# GitHub Actionsでできること
GitHub Actionsは、GitHubのイベントをトリガーとして、コードのチェックアウトやビルドといった一連のコマンドを実行できます。一連のコマンドは以下のコードのようにYAML形式で定義できます。
以降、このコードをもとに各用語やできることを説明します。

サンプルコード:

```sample.yaml
name: Ruby

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: Set up Ruby
      uses: ruby/setup-ruby@v1
      with:
        ruby-version: 2.6
    - name: Install dependencies
      run: bundle install
    - name: Run tests
      run: bundle exec rake
```

## ワークフロー
ワークフローは、後述するジョブが1つ以上存在している自動可能プロセスです。このワークフローをYAML構文で記載したYAMLファイルがワークフローファイルとなります。ワークフローファイルを`Project名/.github/workflows/`に置くことで、GitHub Actionsが動作します。

さきほどのサンプルコードがワークフローであり、そのワークフローにはイベント、ジョブ、ステップ、アクションが含まれています。これらの用語について説明します。

ワークフロー内の分類図:
<img width="600" height="600" alt="" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/406773/a58b7f36-9d15-6703-6c8e-93cba413ba3c.png">

## イベント

```
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
```

イベントは、ワークフロー実行のトリガーとなるGitHubのアクティビティです。また、指定イベントが指定ブランチで発生したときにワークフローを実行させることも可能です。主なイベントして、[pull_request](https://docs.github.com/ja/free-pro-team@latest/actions/reference/events-that-trigger-workflows#pull_request)、[issue](https://docs.github.com/ja/free-pro-team@latest/actions/reference/events-that-trigger-workflows#issues)、[schedule](https://docs.github.com/ja/free-pro-team@latest/actions/reference/events-that-trigger-workflows#schedule)があり、2020/12/09時点で30個のイベントがあります。各イベントについては、GitHubの公式ドキュメントを参照してください。
[GitHub Docs ワークフローをトリガーするイベント](https://docs.github.com/ja/free-pro-team@latest/actions/reference/events-that-trigger-workflows)

サンプルワークフローでは、`push`イベントが`main`ブランチで発生したとき、もしくは`pull_request`イベントが`main`ブランチで発生したときに、ワークフローを実行します。

## ジョブ

```
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: Set up Ruby
      uses: ruby/setup-ruby@v1
      with:
        ruby-version: 2.6
    - name: Install dependencies
      run: bundle install
    - name: Run tests
      run: bundle exec rake
```

ジョブは同じ仮想環境上で実行されるステップの集合であり、ジョブごとに仮想環境の新しいインスタンスで実行されます。ジョブは`runs-on`で指定した環境で実行されます。指定可能な環境は、後述する「Cloud hostsのリソース」の環境に記載しています。

ジョブと仮想環境のイメージ図：
<img width="600" height="600" alt="" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/406773/23eeee0d-46eb-c76e-7866-b913f15876be.png">

ジョブはデフォルトでは並列で実行され、`needs`オプションをつけることで、あるジョブの後に別のジョブを実行することもできます。

[GitHub Docs GitHub Actionsのワークフロー構文 jobs.\<job_id\>.needs](
https://docs.github.com/ja/free-pro-team@latest/actions/reference/workflow-syntax-for-github-actions#jobsjob_idneeds)から抜粋したコード:

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

サンプルワークフローでは、`test`と名付けられた1つのジョブが定義されており、`ubuntu-latest`(Ubuntu 18.04)上でジョブが実行されます。

## ステップ

```
    steps:
    - uses: actions/checkout@v2
    - name: Set up Ruby
      uses: ruby/setup-ruby@v1
      with:
        ruby-version: 2.6
    - name: Install dependencies
      run: bundle install
    - name: Run tests
      run: bundle exec rake
```

ステップは、後述するアクションやコマンドなどを実行できる個別のタスクです。ステップはジョブ内に1つ以上必要です。ジョブ中の各ステップは同じ仮想環境で実行されるため、ジョブ内のアクションはファイルシステムを利用して情報共有可能です。ただし、各ステップは別プロセスとして動くので注意が必要です。

ステップ、ジョブ、仮想環境のイメージ図：
<img width="600" height="600" alt="" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/406773/34425969-c1cb-e77b-e80d-9b5eab6fbb1c.png">

サンプルワークフローでは、ステップは1つのみ定義されており、Rubyのセットアップ、依存関係のインストール、テストの実行タスクの3つを含んだタスクとなっています。

## アクション

```
    - uses: actions/checkout@v2
```

```
      uses: ruby/setup-ruby@v1
```

アクションはステップ内の個々のタスクとなります。GitHub公式のアクションやサードパーティのアクション、独自作成したアクションを使用可能です。

サンプルワークフローでは、GitHub公式が提供している`actions/checkout@v2`、サードパーティのアクションであるrubyの`ruby/setup-ruby@v1`を使用して、コードのチェックアウト、Rubyのセットアップを行っています。

### アクションの種類
アクションには以下の3種類があります。

- GitHubが提供するアクション  
  GitHubが提供するアクション一覧は、さくらインターネットさんがブログでまとめられています。  
  [GitHubの新機能「GitHub Actions」で試すCI/CD](https://knowledge.sakura.ad.jp/23478/)
- GitHub Marketplaceで公開された3rd Partyのアクション  
  AmazonやDockerなどがGitHub Actionsで使用できるアクションを提供しています。  
  [GitHub Marketplace Actions](https://github.com/marketplace?type=actions)
- 独自定義のアクション  
  独自にアクションを定義して使用することもできます。定義できるアクションは、Dockerコンテナ、JavaScriptの2つです。
  - Dockerコンテナのアクション  
    [GitHub Docs Docker コンテナのアクションを作成する](https://docs.github.com/ja/free-pro-team@latest/actions/creating-actions/creating-a-docker-container-action)
  - JavaScriptのアクション  
    [GitHub Docs JavaScript アクションを作成する](https://docs.github.com/ja/free-pro-team@latest/actions/creating-actions/creating-a-javascript-action)

# 実行環境

GitHub Actionsの実行環境を図として表すと以下のようになります。Cloud hosts上でGitHub-hosted runnersが動作しジョブを実行します。またGitHub-hosted runners上で、コンテナ（図のContainerやService Container）を使用したジョブの実行やデータベースとの通信も可能です。

実行環境イメージ図：

<img width="600" height="600" alt="" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/406773/a7fb6c0c-3108-9388-8178-44259d39b371.png">

実行環境の図にあるCloud hosts、GitHub-hosted runners、Container、Service Containerについてそれぞれ説明します。

## 環境
### Cloud hosts

<img width="600" height="600" alt="" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/406773/7d51bb01-97f2-939f-78b2-6f69f3bbcc84.png">

Cloud hostsは、後述するGitHub-hosted runnersを実行させる環境です。GitHub-hosted runnersで使用するOSごとにCloud hostsが異なります。

|GitHub-hosted runnersで使用するOS |Cloud hosts |
|---|---|
|Ubuntu |[Microsoft Azure Standard_DS2_v2](https://docs.microsoft.com/ja-jp/azure/virtual-machines/dv2-dsv2-series)|
|Windows Server |[Microsoft Azure Standard_DS2_v2](https://docs.microsoft.com/ja-jp/azure/virtual-machines/dv2-dsv2-series)|
|macOS |[MacStadium](https://www.macstadium.com/) |

#### Cloud hostsのリソース
Microsoft Azure、MacStadiumのどちらでも、使用するリソースは同一のハードウェアリソースです。GitHubの公式ドキュメントから抜粋します。

- 2コアCPU
- 7 GBのRAMメモリー
- 14 GBのSSDディスク容量

|仮想環境  |YAMLのワークフローラベル  |
|---|---|
|Windows Server 2019 |windows-latest or windows-2019 |
|Ubuntu 20.04 |ubuntu-20.04 |
|Ubuntu 18.04 |ubuntu-latestまたはubuntu-18.04 |
|Ubuntu 16.04 |ubuntu-16.04 |
|macOS Big Sur 11.0 |macos-11.0 |
|macOS Catalina 10.15 |macos-latestもしくはmacos-10.15 |

[GitHub Docs GitHub ホストランナーの仕様
](https://docs.github.com/ja/free-pro-team@latest/actions/reference/specifications-for-github-hosted-runners)

### GitHub-hosted runners

<img width="600" height="600" alt="" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/406773/18e3a0bd-3303-e641-c288-4361e0a54638.png">

GitHub-hosted runnersはCloud hosts上で動作する仮想環境です。このGitHub-hosted runnersには、オープンソースであるGitHub Actionsランナーアプリケーションの[runner](https://github.com/actions/runner)がインストールされています。
また、このGitHub-hosted runnersのOSにはUbuntu、Windows Server、macOSを指定可能です。（2020年12月9日時点）

### Container

<img width="600" height="600" alt="" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/406773/326a9621-7f5b-658d-562e-a1fb909563f9.png">

ContainerはDockerコンテナであり、ジョブの実行場所として指定可能です。このDockerコンテナで指定可能なイメージは、通常のDockerコンテナと同様、Docker HubやパブリックなDockerレジストリにあるイメージとなります。

### Service Container

<img width="600" height="600" alt="" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/406773/4a6dc3c2-8f0b-c846-741b-ccd74c46e115.png">

Service Containerはジョブごとに定義可能なDockerコンテナです。このService Containerはジョブ内の処理と通信することができますが、Service Containerが定義されたジョブと同じジョブにある各ステップのみとなります。またジョブ完了時には、Service Containerは破棄されます。
このService Containerの用途としては、データベースへのアクセスが必要なテストをジョブで実行したいときに使うといった場合があります。

#### Service Containerとの通信
Service Containerとの通信方法は、ジョブの実行場所により異なります。ジョブの実行場所がGitHub-hosted runners上の場合はポート番号によるアクセス、GitHub-hosted runners上のContainer上の場合はラベルによるアクセスとなります。

Service Containerとの通信方法イメージ図：
<img width="600" height="600" alt="" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/406773/3692da20-5bcc-25f2-180d-ddc4c0266dc9.png">

### 管理権限
LinuxやmacOSの仮想環境を使う場合、sudoのパスワードは不要です。またWindowsの仮想環境を使う場合、ユーザアカウント制御（UAC）は無効となり管理者として動作します。

# 制限事項
GitHubの公式ドキュメントから抜粋します。
>・ジョブの実行時間 - ワークフロー中のそれぞれのジョブは、最大で6時間の間実行できます。 ジョブがこの制限に達すると、ジョブは終了させられ、完了できずに失敗します。

>・ワークフローの実行時間 - 各ワークフローの実行は72時間までに制限されます。 ワークフローの実行がこの制限に達すると、そのワークフローの実行はキャンセルされます。

>・APIリクエスト - リポジトリ内のすべてのアクションにわたって、1時間のうちに最大1000回のAPIリクエストを実行できます。 この制限を超えた場合、超過のAPIコールは失敗し、それによってジョブも失敗するかもしれません。

>・並行ジョブ - アカウント内で実行できる並行ジョブ数は、以下の表に示すとおり、利用しているGitHubのプランによります。 この制限を超えた場合、超過のジョブはキューイングされます。

|GitHubプラン |最大同時実行ジョブ |最大同時macOSジョブ | 
|---|---|---|
|無料 |20 |5 |
|Pro |40 |5 |
|Team |60 |5 |
|Enterprise |180 |50 |

> ジョブマトリックス - ジョブマトリックスは、ワークフローの実行ごとに最大で256のジョブを生成できます。 この制限は、セルフホストランナーにも適用されます。

[GitHub Docs 使用制限、支払い、管理](https://docs.github.com/ja/free-pro-team@latest/actions/reference/usage-limits-billing-and-administration)

制限事項は今後変わる可能性があるので、使用される際は注意が必要です。個人の意見として、CI/CDとしてジョブやワークフローでこの制限に引っかかることはほとんどないと思われます。もし引っかかるようであれば、どこかでボトルネックになっている部分があると考えられるので、そのボトルネックの改善が必要ですね。

# 利用料金
パブリックリポジトリで使用する場合は無料で使えます。一方、プライベートリポジトリの場合は、GitHubアカウントの契約プランによって無料で使える範囲とストレージが決まります。またGitHub Actions利用料金の上限はデフォルトで0ドルとなっています。
そのため無料の範囲を超過し、かつ利用料金の上限がデフォルトの0ドルままであれば、GitHub Actionsは使用不可となります。利用上限を0ドル以上に設定した場合は、無料の範囲を超えた利用時間やストレージ料が請求されます。
請求金額や計算方法の詳細はGitHubの公式ドキュメントを参照してください。

[GitHub Docs 使用制限、支払い、管理](https://docs.github.com/ja/free-pro-team@latest/actions/reference/usage-limits-billing-and-administration)
[GitHub Docs GitHub Actionsの支払いについて](https://docs.github.com/ja/free-pro-team@latest/github/setting-up-and-managing-billing-and-payments-on-github/about-billing-for-github-actions)

# ローカル環境でGitHub Actionsを実行
ローカル環境でGitHub Actionsを実行できるGitHub公式のツールはありませんが、別の方々が作成されたオープンソースの[act](https://github.com/nektos/act)があります。actはGitHub Actionsをローカルで実行できるGolangのツールです。使用方法や実際に使ってみた記事はこちらに記載しています。

[GitHub ActionsでRun rubocop with reviewdogを使ったCIの構築](https://qiita.com/M-Yamashii/items/a4d9d530f13c31e0f889)

# 今後のGitHub Actions
GitHubが公開しているroadmapにて、GitHub Actionsの今後の機能追加について記載されています。この中には、GitHub-hosted runnersのリソースを複数選べるようにする機能（[Actions: Multiple hosted runner sizes, custom networking, and custom images #95](https://github.com/github/roadmap/issues/95)）や、プライベートリポジトリのアクションを使用可能にする機能（[Actions: Use actions from private and internal repositories #74](https://github.com/github/roadmap/issues/74) ）などがあります。

<img width="600" height="600" alt="" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/406773/fe2343a5-1ea6-ae12-5427-e684be2b7528.png">
[roadmap GitHub public roadmap](https://github.com/github/roadmap/projects/1?card_filter_query=label%3Aactions)

# まとめ
GitHub Actionsの誕生の歴史やサンプルワークフローを使った用語の説明、GitHub Actionsの環境を説明しました。はじめてGitHub Actionsを触る人にとって、この記事がお役に立てれば幸いです。またここに書ききれなかったGitHub Actionsの機能やオプションなどたくさんありますので、GitHub公式のドキュメントも確認されてみてください。
[GitHub Docs GitHub Actions](https://docs.github.com/ja/free-pro-team@latest/actions)

明日は[@que9](https://qiita.com/que9)さんの記事です。お楽しみに。

# その他参考資料
[Dockerコンテナ時代の第一章の終わり、そして第二章の展望など](https://www.publickey1.jp/blog/17/post_265.html)
[The Linux Foundation](https://www.linuxfoundation.org/trademark-usage/)
[The Moby Project](https://github.com/moby/moby)
[GitHub Docs GitHub Actions 入門](https://docs.github.com/ja/free-pro-team@latest/actions/learn-github-actions/introduction-to-github-actions)
[GitHub Docs ワークフロー データをアーティファクトとして保存する](https://docs.github.com/ja/free-pro-team@latest/actions/guides/storing-workflow-data-as-artifacts)
[GitHub Docs GitHub Actionsのワークフロー構文](https://docs.github.com/ja/free-pro-team@latest/actions/reference/workflow-syntax-for-github-actions)
[GitHub Docs GitHub ホストランナーの仕様](https://docs.github.com/ja/free-pro-team@latest/actions/reference/specifications-for-github-hosted-runners)
[GitHub Docs サービスコンテナについて](https://docs.github.com/ja/free-pro-team@latest/actions/guides/about-service-containers)