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されたら |
非常にトリガーが豊富ですね。
詳細はこちらをご覧ください。
トリガーを組み立てる
次はトリガーをもらって、何をするかを定義します。
以下のようにトリガー枠の青い点を点線にドラッグしてつなぎます。
ビルドインですでにいくつか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のようにログをみることができます。
気になる点
Workflowの差分はどのように見れるのか?
試しにActionの名前をHello WorldからEnd Worldに変更し、プルリクを投げてみます。
しかもresolve(=トリガーとAction)を繋げ忘れたことをCheckしてくれました。
差分自体はPlain Textでみることになりそうです。
Visual Editorで複雑なWorkflowは定義できるの
現時点ではできないようです。
新しいActionはPlain Textでしか作成できないみたいです。
まとめ
まだまだドキュメントも豊富ではありませんが、Githubにソースコードを置かないチームはなかなかないので、Githubだけで完結してくれると非常に嬉しいです。
特にCIは種類も豊富で、できることできないことを把握して技術選定するのが面倒なので、GithubActionsがデフォルトスタンダードになってくれるといいなと思います。
