Github Actions - 基本概念と使い方

目的

GithubのCI/CDツールであるGithub Actionsの概念と使い方を学ぶ。
Infrastructure as codeに基づいて、GUIやCUIではなく構成ファイルを作成する方法を学ぶ。

Github Actionsとは

GithubのCI/CDツール
今までGithubとCI/CDツールは異なるSaaSを使う必要があったが、Github Actionsによってひとつに統一される
2019年11月13日に安定版がリリースされた

Github Actionsの用語集

Github Actionsを使う上で知っておくべき用語をまとめる
ピンと来ないものがあれば、後でWorkflow fileを書いていくのでその時に見返せば実感が沸くはず

Workflow

Workflowは１つまたは複数のJobから構成される
Jobの例としては、build, test, package, release, deployがある
このWorkflowは、cronでスケジュールされるか、事前に決めたイベントが生じたときに動き出す
事前に決められるイベントの例は、リポジトリへのPush、プルリク、Webhookを使った外部のイベントがある

Workflow file

Workflow fileはリポジトリ内の.github/workflowsディレクトリに置かれたYAMLファイルのこと
これにWorkflowの構成を書く

Job

JobはWorkflow file内でStepの集まりとして定義される（Stepは後で紹介する）
Jobの識別子は前述したように、build, test, package, release, deployなどがある
複数のJobがある場合、それらを同時に実行したり、順番に実行したりできる
デフォルトではすべてのJobが同時に実行される
Jobを順番に実行していく場合は、一つ前のJobが成功した場合だけその後のJobが実行される

Step

Jobを構成するActionやCommandの集まり(ActionとCommandはすぐ下で紹介する)
YAMLファイルの中では、Actionはuses、Commandはrunというキーで指定される

Action

Stepを構成する最小単位で、自分で作ったもの使ったり、Githubコミュニティで共有されているものを使ったり、パブリックなものを編集したりできる
Github ActionsではこのActionを使ってWorkflowを構成していくのが基本となるようだ

Command

CommandはこのWorkflowが実行される環境のOSで使えるコマンドの事
Linux, macOS, Windowsを選択でき、Workflowではそれらのコマンドを使うことができる

文法

ここからは、Workflow fileにWorkflowを書いていく
workflow fileは.github/workflowsに置く

Workflow の実行

Workflowは事前に決めたイベントが起きた時に実行されると述べた
今回はcronとpushとpull requestイベントをトリガーにする方法を書く
ちなみに、cronとpushをトリガーとして一緒に設定したときに、cronは実行されなかった

トリガー：cron

cronは "* * * * *"のように５つのセクションから成り
左から順に、分(0~59)、時(0~23)、日(1~31)、月(1~12)、曜日(0~6 0=日曜日)
*はすべての値を意味する
以下の例では、毎時Workflowが実行される

cron.yaml

name: workflow-name
on:
  schedule:
    - cron: "0 * * * *"

トリガー：Push

レポジトリへのPushをトリガーとする、おそらくもっとも一般的なトリガー
今後の説明ではこのトリガーを用いて説明していく

push.yaml

name: workflow-name
on: push

トリガー：pushとプルリク

プルリクも頻繁に行われると思うので追加する
以下のように[]にカンマ区切りで書けば複数指定できる

push.yaml

name: workflow-name
on: [push, pull_request ]

BranchとTagによるフィルター

単純にon: pushと書くとすべてのブランチでpushしたときにWorkflowが起動する
ブランチやタグごとにWorkflowの構成を分けたい時にはフィルターを用いる

以下の書き方では、masterブランチへのpushと、v1というタグをpushしたときにWorkflowが起動する

filter.yaml

name: workflow-name
on:
  push:
    branches:
      - master
    tags:
      - v1

実行環境を指定する

一つの実行環境

我々はJobの実行環境としてUbuntu, Linux, macOSなどを選ぶことができる
また、buildとtestという二つのジョブを作ったときに、それぞれ別の実行環境で動作を確認できる

以下の例では、ubutu-18.04の環境でJobを登録している
内容は、echo "Hello World"というCommandがうまくいくかというもの

command.yaml

name: workflow-name
on: push

jobs:
  build:
    name: Greeting
    runs-on: ubuntu-18.04
    steps:
      - name: Hello World
        run: echo "Hello World"

複数の実行環境

さっきはubuntu-18.04だけの確認だった
build matrixというものを使うと複数の実行環境での動作確認をできる
以下の例ではubuntu-16.04とubuntu-18.04で実行させている

buildmatrix.yaml

name: workflow-name
on: push

jobs:
  build:
    name: Greeting
    runs-on: ${{matrix.os}}
    strategy:
       matrix:
         os: [ubuntu-18.04, ubuntu-16.04]
    steps:
      - name: Hello World
        run: echo "Hello World"

Actionを使う

Github Actionsの肝？だと思われるActionを使う
今回はすでにGithubコミュニティで用意されているものを使ってみる
自分でも作ることができるみたい

action.yaml

name: Greet Everyone
on: push

jobs:
  build:
    name: Greeting
    runs-on: ubuntu-latest
    steps:
      - name: Hello World
         # GithubコミュニティのActionを使う
        uses: actions/hello-world-javascript-action@v1
         # withはactionへの入力パラメータのkey/valueのペア
        with:
          who-to-greet: "hoge"