Github Actionsが使えるようになったので使ってみる

本記事

本記事では、少し前にアナウンスされたGithub ActionsというCIツールのようなものを実際に触ってみて、現時点での使い勝手をまとめてみようと思います。

実際に使えるようになると以下のようなタブが追加されています。

まだベータ版ですが使うには申し込む必要があるので、このリンクから申し込んでください。

初めて使ってみる

ActionページにいってWorkflowを作ってみる

Actionページに行くと以下のようなページでWorkflowを作り始められます。

"Create a new workflow"を押して開始してみます。

Visual Editor

基本的なこと

以下のように設定できます。

いくつものWorkflowを定義できるようです。

一つ目のActionのEditをおしてみます。

これはトリガーです。

どのようなことが起きればこのWorkflowが走るか

を定義するものです。

Runで定義するトリガーは以下のものがあります。

項目	トリガー条件
check_run	Checkが走ってcreated, rerequested, requested_actionになったら
check_suite	Check runの集合で、ステータスがcompleted, requested, rerequestedになったら
commit_comment	コミットコメントがcreatedになったらトリガー
create	ブランチやタグが作られたら
delete	ブランチやタグが削除されたら
deployment	APIを通してデプロイメントが作られたら
deployment_status	デプロイメントステータスが更新されたら
fork	リポジトリがフォークされたら
gollum	Wikiページがアップデートされたら
issue_comment	Issueにコメントがcreated、editedかdeletedされたら
issues	Issueがassigned, unassigned, labeled, unlabeled, opened, edited, milestoned, demilestoned, closed, reopenedされたら
label	ラベルがcreated, edited, deletedしたら
member	メンバーが招待、削除に追加されたり権限が変わったら
milestone	マイルストーンがcreated, closed, opened, editedかdeleted`されたら
page_build	ページサイトがbuiltされたり失敗されたら
project_card	Project Cardがcreated、edited, moved, Issueにconvertedかdeletedされたら
project_column	Project Columnがcreated, edited, movedかdeletedされたら
project	Projectがcreated, edited, closed、reopenend, deletedされたら
public	リポジトリがPrivateからPublicに変わったら
pull_request_review_comment	Pull requestにreviewコメントがついたら
pull_request_review	Pull requestがreviewされたら
pull_request	Pull requestがassigned, openedなどしたら(多すぎて省略します)
push	tagやコミットがpushされたら
repository_vulnerability_alert	vulnerability alertが通知されたら
release	リリースが作成されたら
repository_dispatch	他のユーザーがアプリのイベントをトリガーしたら
status	リポジトリステータスがAPIによって変更されたら
watch	ユーザーがリポジトリがStarされたら

2019/07/25
@yui_tang さんに指摘され、deleteの説明欄の間違いを修正しました！ありがとうございます！

非常にトリガーが豊富ですね。

詳細はこちらをご覧ください。

トリガーを組み立てる

次はトリガーをもらって、何をするかを定義します。

以下のようにトリガー枠の青い点を点線にドラッグしてつなぎます。

ビルドインですでにいくつかActionがあります。
また、GCPを使う人は、かなり簡単にアクションを作ることができるとおもいます。

適当に自前のRun Actionを定義します。

環境変数を定義

また、環境変数を定義することができます。

あとで解説しますが、再利用可能なActionsにすることができます。

Secretも定義

また、Secretも定義できます。

Plain Textで保存するのはセキュリティ的にあれということがあればGoogle KMSなどを合わせて使うと安全でしょう。参考リンク

Workflowを保存する

あとで解説しますが./.github/以下にワークフローの設定ファイルが保存されます。

右上でコミットして保存します。

ファイルで設定もできる

先ほどWorkflowを保存しましたが、同様に./.github/hogehoge.workflowと.workflowがつく名前で定義することができます。

これによって宣言的にWorkflowを定義することができます。

このような感じで保存されています。

そして、プレビューでVisual Modeでみることができます。

実際は以下のようなファイルになっています。

workflow "New workflow" {
  on = "push"
  resolves = ["Hello World"]
}

action "Hello World" {
  uses = "./say_hello.sh"
  env = {
    MY_NAME = "KeisukeYamashita"
  }
  args = "\"Hello world, I'm $MY_NAME!\""
}

• on: トリガーのイベント
• resolves: Actionを解決する

ログも見れる

Check APIのようにログをみることができます。

YAMLの設定方法(追記: 2019/08/20)

正式にCI/CDがサポートされたのでYAMLの書き方を紹介します。

1. .github/workflows以下に設定を書く

workflowは１つに限らず、複数、書くことができます。

2. Workflowの設定を書く

まず、ルートレベルにWorkflowの設定を書き込みます。

name: WORKFLOW_NAME
on: [push, pull_request]

単一のイベントだけならば以下のようにします。

name: WORKFLOW_NAME
on: [push, pull_request]

そのイベントの中でも、どれかのファイルに絞りたいときは以下のように指定します。

paths:       # Push events containing matching files
  - test/*
  - *.xml

このonはワークフローが実行される条件です。Pull Request限らず、書くことができるのがよいところです。またかきますが、以下のようなイベントでワークフローを書くことができます。

項目	トリガー条件
check_run	Checkが走ってcreated, rerequested, requested_actionになったら
check_suite	Check runの集合で、ステータスがcompleted, requested, rerequestedになったら
commit_comment	コミットコメントがcreatedになったらトリガー
create	ブランチやタグが作られたら
delete	ブランチやタグが削除されたら
deployment	APIを通してデプロイメントが作られたら
deployment_status	デプロイメントステータスが更新されたら
fork	リポジトリがフォークされたら
gollum	Wikiページがアップデートされたら
issue_comment	Issueにコメントがcreated、editedかdeletedされたら
issues	Issueがassigned, unassigned, labeled, unlabeled, opened, edited, milestoned, demilestoned, closed, reopenedされたら
label	ラベルがcreated, edited, deletedしたら
member	メンバーが招待、削除に追加されたり権限が変わったら
milestone	マイルストーンがcreated, closed, opened, editedかdeleted`されたら
page_build	ページサイトがbuiltされたり失敗されたら
project_card	Project Cardがcreated、edited, moved, Issueにconvertedかdeletedされたら
project_column	Project Columnがcreated, edited, movedかdeletedされたら
project	Projectがcreated, edited, closed、reopenend, deletedされたら
public	リポジトリがPrivateからPublicに変わったら
pull_request_review_comment	Pull requestにreviewコメントがついたら
pull_request_review	Pull requestがreviewされたら
pull_request	Pull requestがassigned, openedなどしたら(多すぎて省略します)
push	tagやコミットがpushされたら
repository_vulnerability_alert	vulnerability alertが通知されたら
release	リリースが作成されたら
repository_dispatch	他のユーザーがアプリのイベントをトリガーしたら
status	リポジトリステータスがAPIによって変更されたら
watch	ユーザーがリポジトリがStarされたら

3. Job: トリガーされたときの一連のタスクを定義する

job.<job_id> で指定をします。サンプルでは以下のようにあります。

jobs:
  my_first_job:
    name: My first job
  my_second_job:
    name: My second job

3.0 uses: コードを再利用

パブリックリポジトリのワークフローや、公式のジョブを使うことができます。

もっとも使うのは以下の checkout　ジョブでしょう。ワークフローの実行環境へコードをcheckoutしてくれます。

uses: actions/checkout@master

一覧はGithub Actions repositoryで見ることができます。

3.1 runs-on: マシンの設定

これらがどのマシンで動くかは、以下のように設定ができます。

• ubuntu-latest, ubuntu-18.04, または ubuntu-16.04
• windows-latest, windows-2019, または windows-2016
• macOS-latest または macOS-10.14

3.2 コンテナの設定

以下のようにコンテナを使って実行することができます。

jobs:
  my_job:
    container:
      image: node:10.16-jessie
      env:
        NODE_ENV: development
      ports:
      - 80
      volumes:
      - my_docker_volume:/volume_mount
      options: --cpus 1

volumeのマウントをすることができます。

4. Secretの設定

SecretはリポジトリのSettings -> Secretから設定ができます。

設定をするには以下のようにします。

env:
   GOOGLE_APPLICATION_CREDENTIALS: ${{ secrets.GOOGLE_APPLICATION_CREDENTIALS}}

5. CronJobを設定

実はGithub ActionsでもCronJobを設定することができます。

on:
  schedule:
    # * is a special character in YAML so you have to quote this string
  - cron:  '0 * * * *'

このようにonをCronTabのように設定をすることで使うことができます。

6. Eventの情報を取得する

環境変数GITHUB_EVENT_PATHで指定されている/github/workflow/event.jsonで指定できて、これがEventのPayloadになっています。

実際に、Payloadに使われるのはREST API v3で指定できるようなものです。

例えばPull RequestがきたときはPullRequestEventオブジェクトができます。使いたいイベントに合わせてオブジェクトを調べると、色んな事ができると思います。

気になる点

Workflowの差分はどのように見れるのか?

試しにActionの名前をHello WorldからEnd Worldに変更し、プルリクを投げてみます。

しかもresolve(=トリガーとAction)を繋げ忘れたことをCheckしてくれました。

差分自体はPlain Textでみることになりそうです。

Visual Editorで複雑なWorkflowは定義できるの

現時点ではできないようです。

新しいActionはPlain Textでしか作成できないみたいです。

Status Badgeみたいなのはあるの？

探している感じ、ありそうではないです。
しかし、MergeをしてGithub Workflowがはしっている状態だと、このように知ることはできます。

後に実装されるのではないかと期待をしています。そして、MasterでのWorkflowが無事、終了すると以下のようになります。

まとめ

まだまだドキュメントも豊富ではありませんが、Githubにソースコードを置かないチームはなかなかないので、Githubだけで完結してくれると非常に嬉しいです。

特にCIは種類も豊富で、できることできないことを把握して技術選定するのが面倒なので、GithubActionsがデフォルトスタンダードになってくれるといいなと思います。

参考文献

公式ドキュメント

GitHub Actions | GitHub Developer Guide

YAMLの公式のDocument

Workflow syntax for GitHub Actions