Edited at

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にコメントがcreatedediteddeletedされたら

issues
Issueがassigned, unassigned, labeled, unlabeled, opened, edited, milestoned, demilestoned, closed, reopenedされたら

label
ラベルがcreated, edited, deletedしたら

member
メンバーが招待、削除に追加されたり権限が変わったら

milestone
マイルストーンがcreated, closed, opened, editeddeleted`されたら

page_build
ページサイトがbuiltされたり失敗されたら

project_card
Project Cardがcreatededited, moved, Issueにconverteddeletedされたら

project_column
Project Columnがcreated, edited, moveddeletedされたら

project
Projectがcreated, edited, closedreopenend, 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の説明欄の間違いを修正しました!ありがとうございます!

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

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

https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events


トリガーを組み立てる

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

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

ビルドインですでにいくつか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は1つに限らず、複数、書くことができます。


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にコメントがcreatedediteddeletedされたら

issues
Issueがassigned, unassigned, labeled, unlabeled, opened, edited, milestoned, demilestoned, closed, reopenedされたら

label
ラベルがcreated, edited, deletedしたら

member
メンバーが招待、削除に追加されたり権限が変わったら

milestone
マイルストーンがcreated, closed, opened, editeddeleted`されたら

page_build
ページサイトがbuiltされたり失敗されたら

project_card
Project Cardがcreatededited, moved, Issueにconverteddeletedされたら

project_column
Project Columnがcreated, edited, moveddeletedされたら

project
Projectがcreated, edited, closedreopenend, 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