Help us understand the problem. What is going on with this article?

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

More than 1 year has passed since last update.

本記事

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

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

image.png

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

初めて使ってみる

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

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

image.png

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

Visual Editor

基本的なこと

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

image.png

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

image.png

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

image.png

これはトリガーです。

どのようなことが起きればこの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

トリガーを組み立てる

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

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

hoge.gif

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

image.png

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

image.png

環境変数を定義

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

image.png

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

Secretも定義

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

image.png

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

Workflowを保存する

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

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

image.png

ファイルで設定もできる

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

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

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

image.png

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

image.png

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

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のようにログをみることができます。

image.png

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から設定ができます。

image.png

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

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に変更し、プルリクを投げてみます。

image.png

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

image.png

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

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

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

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

image.png

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

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

image.png

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

image.png

まとめ

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

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

参考文献

公式ドキュメント

GitHub Actions | GitHub Developer Guide

YAMLの公式のDocument

Workflow syntax for GitHub Actions

1915keke
mercari
フリマアプリ「メルカリ」を、グローバルで開発しています。
https://tech.mercari.com/
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away