本記事
本記事では、少し前にアナウンスされた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