対象の読者

Travis-CIやCircleCIなどのGithubと統合されたモダンなCIサービスを使ったことがあり、その使い方をおおよそ理解している人向けに書いています。

Travis-CIやCircleCIなどのモダンCIサービスとGithub Actionsで違う点

使い方はほぼ同じです。GitリポジトリそのものにコミットされたCI設定ファイル( .github/workflows/workflow-a.yml など)を読み取りGitリポジトリへのアクション駆動でCIが走ります。

CIの実行状況やログがウェブ上で確認できる点も同じです。
以下のようにCIステータス確認用のCIバッジの機能もあります。

利用料金が安い(というかだいたい無料)

個人ではなく組織で利用することを考えた場合、例えばCircleCIの利用料金は1ユーザー$15です¹(料金プラン - CircleCI)。
それに対してGithub Actionsの利用料金はGithub自体の利用料金へ含まれており、基本的に追加の費用はかかりません。従来Githubの有料プランを使っていた人は追加投資0で利用できることになります²。各プランごとに基本で提供されるCI実行時間(Teamプランで3,000分/月 = 計50時間/月)を超えるとCIが実行できなくなりますが、追加料金を支払うことでそれ以上の実行も可能になります(About billing for GitHub Actions - GitHub ヘルプ)。

蛇足: Github Actions安すぎない？

Githubとの高い統合性(使いやすさ)

Travis-CIやCricleCIなどのCIサービスがよく普及した背景にはwebhookによるCIの自動キックやコミットへのCI結果表示、最新のCIステータスバッジなどもあると思います。それらがGithubとの統合性を高め、サービス初心者でも簡単に利用できるようにしています。

Github Actionsでは更にそれらより一歩楽になっています。
Github Actionsは標準で有効になっているため設定ファイルを追加するだけでCIが自動的に走ります。TravisやCircleなどでやるような初期設定が不要です。
またGithubからの遷移の面でも「Actions」タブによってより理解しやすくアクセスがよりしやすくなっています。

またCircleやTravisが備えているものと同様のステータスバッジ生成機能もあります。

再利用可能なCI処理パーツというアイデア(Action)

これまでに書いた利点が「自身がGitリポジトリホスティングサービスであるポジショニング的利点」「Microsoftという強力な資金源」というやや卑怯なメリットであったのに対して、この利点は純粋にCIサービスの機能であり、個人的には革新的な改善だと思っています。
詳しく説明しましょう。

GitHub Actionsのワークフロー構文 - GitHub ヘルプ

Github Actionsの用語として、まずCI設定ファイルはワークフローファイルと呼ばれます。1つのワークフローファイルには1つ以上のジョブから構成されます。1つのジョブは逐次実行される1つ以上のステップからなります。

• ワークフローファイルα
  • …
• ワークフローファイルβ
  • ジョブA
    • …
  • ジョブB
    • ステップ1
    • ステップ2
      • 以下のどれか
        • コマンドの実行
        • 設定タスクの実行
        • Actionの実行
    • …
  • ジョブC
    • …
  • …
• …

ステップでは、コマンドを実行する、設定タスクを実行する、あるいはリポジトリやパブリックリポジトリ、Dockerレジストリで公開されたアクションを実行することができます。

ドキュメントにかかれている通りこのステップではTravisやCircleでやったようなシェルスクリプトのプリミティブな実行(= コマンドの実行)もできますが、アクションも実行することができます。
このアクション、簡単に言うと再利用可能なCIスクリプトです。
代表的なものがActions | GitHubのページに並んでいますがAWSへの接続に必要な認証の設定をよしなにしてくれるaws-actions/configure-aws-credentialsやKubernetesへのデプロイをしてくれるAzure/k8s-deployなどがあります。
これを使えばCIのスクリプトを自分で書くことなく、十分に検証された処理を選ぶだけで良くなります。

ディレクトリ単位でCIをキックするかを判定できる

地味ながら重要な点です。自分が知る限りTravic-CIでもCircleCIでも特定のディレクトリ以下が変更された場合のみCIを実行する、という設定はできません。
Github Actionsではon.<push|pull_request>.pathsという設定でそれを行うことができます。
最近ではモノレポと言われる戦略が有名になってきたりそうでなくとも1つのリポジトリへterraformファイル・アプリケーションコード・lambda定義など複数の種類のデプロイに関わるコードが集約されることがあります。そういったときにはこの設定ができないとCIのためにリポジトリを分ける、ということをしなければなりません。
地味ですが非常に重要な機能だと思います。

頑張ってほしいポイント

UI・UXはTravisやCircleに劣る

主観や慣れによるところも大きいですが実行中のジョブの状態表示や実行ログの表示などはまだTravisやCircleなど既存のサービスのほうが洗練されている印象です。

特にGithub Actions側は実行されたワークフローのログに到達するまでの遷移数・クリック数が非常に多いです。
Travisがページさえ開けば即座にログが表示されるのに対してGithub Actionsはログを表示するまで2,3回多くのクリックを必要とします。

2020/09/24 ログの表示が改善されました！

詳細はこちら: A better logs experience with GitHub Actions - The GitHub Blog

あまりに重すぎて長いログだと使えるかギリギリの品質だったログ表示がだいぶ改善されました。
ただ、他のCIサービスと比べると正直まだまだかなと思います。

外部のActionsを使ったときのセキュリティが非常に怖い

現在ActionはGitHub Marketplace · Actions to improve your workflowで公式に列挙されていますが、これらもセキュリティ的になんらチェックされているわけではありません。
例えば最悪のケースとしてawsの認証情報を設定するActionが裏で外部に認証情報を送っていた、ということも考えられます。また現在はそういったコードになっていなかったとしても多くのactionはmasterブランチないしv1, v2などのタグで参照されているため、あとからそういったコードに入れ替えられる可能性もあります。
Actionの開発元がAWSやAzure、あるいは有名企業である場合はそれがある意味の担保になりますのでそこを信用して使っているという人もいると思いますが、そのノリで個人開発のActionをうっかり使うと知らずにリスクを抱えてしまいます。

解決策ですが、以下に書かれています。

GitHub Actionsのワークフロー構文 - GitHub ヘルプ

リリースされたアクションバージョンのコミットSHAを使用するのが、安定性とセキュリティのうえで最も安全です。

GitのコミットSHAはコードの状態ごとに変わるためコミットSHAで指定すると勝手にコードを改変される恐れはありません。もちろんその時点でコードに不審な処理がない前提ですので、個人やよくわからない企業のActionを使う際には①コードの中身をチェックする ②その時点のコミットのSHAでワークフロー中は指定する の行程が必須になります。

ただ、現実には多くのhow to useで@materや@v1などが書かれているのが現状です。
Github公式のActionですらほとんどタグ指定やブランチ指定で書かれています。
コミットSHAによる指定は啓蒙していきたいですね。

2020/10/06 外部のアクションを使用するときのセキュリティが向上しました！

詳細はこちら: Fine-tune access to external actions - The GitHub Blog

[些細な点]生成されるステータスバッジのコードが微妙

CIサービスにおけるステータスバッジとはこれです。

Actions · bigwheel/tfinfermv

上のようにActionsタブから個別のワークフロー画面へ行くと右上へ「Create status badge」ボタンが出るのですが、それによりGithub Actionsが生成するコードが以下です。

![CI](https://github.com/bigwheel/tfinfermv/workflows/CI/badge.svg)

一方Travis-CIなどが生成するコードはこうなっていることが多いです。

[![Build Status](https://travis-ci.org/bigwheel/util-backports.svg?branch=master)](https://travis-ci.org/bigwheel/util-backports)

何が違うのかというとステータスバッジをクリックしたときの挙動が違います。
Github Actions側は単なる画像へのリンク(実例 → )なので画像が表示されるだけなのに対して後者はそのCI実行結果へのリンクになっているためGreen/Redになったその原因のCIへ直接飛べます(実例 → )。
これでは不便なので僕は毎回Github Actionsのステータスバッジコードを以下のように修正しているのですが(実例 → )なかなか面倒です。

[![CI](https://github.com/bigwheel/tfinfermv/workflows/CI/badge.svg)](https://github.com/bigwheel/tfinfermv/actions?query=workflow%3ACI)

落とし穴

Github Actionsは正式公開が2019/11と、まだ4ヶ月しか経っていないサービスです(初稿作成時点)。そのためいろいろと行き届いていなかったりまだ良く知られていない機能や事項があります。ここでは個人的にハマったりした点を上げます。

公開されているActionの種類・品質がまだまだ低い

現状GithubのMarketplaceへ登録されたActionは2020/02/29時点で2390個あります。

GitHub Marketplace · Actions to improve your workflow

一見たくさんあるように見えますが、同じ目的のActionが乱立しており定評があるActionなどが定まっておらず選択にはそこそこ苦労します。例えばSlackへの通知に使えるActionはだいたい30個ぐらいあり(GitHub Marketplace · Actions to improve your workflow)、選択基準の一つであるStarの数も最高で140かつ100前後のActionが4つあります。

またより辛いのはGithub自身やMicrosoftなどの大手IT企業が管理しているActionもまだ動向が定まっておらず安定して使えないケースがあることです。

• aws/kubectl at master · actions/aws

ここにはgithub公式が管理しているaws向けのactionがあったのですが2019/12/04に「このActionは年内に廃止するよ」と言われて急いで移行する必要がありました(すでにリポジトリごと消されています)。
また同じくkubernetes関連ですがMicrosoftが管理しているkubectl用Actionにはかなり致命的なバグがv1に含まれていたのですが、その修正PRがマージされてから2ヶ月以上経ってもまだv2やv1.1はリリースされていません。ではmasterブランチを参照しようと思ったんですがmasterブランチには別の致命的なバグがあり、結局私はPRを作った人のfork版リポジトリを参照している状態です。

このように正式公開されたとはいえまだカオス度が高いのが公開Actionの現状です。
公開ActionはほとんどOSSなので最悪自分でforkする、などの対応は覚悟しましょう。

正式公開(2019/11)以前と以後でワークフローファイルのフォーマットから構造まで違う

Github Actionsは2018年からベータ状態で提供されていたのですが、その少し前にワークフローファイルのフォーマットがHCLからyamlへ変更されています。

新 GitHub Actions 入門 - 生産性向上ブログ

Support for the HCL syntax in GitHub Actions will be deprecated on September 30, 2019.

ただ、現時点ではまだまだ古いHCLの書き方で書かれたドキュメントやサンプル・ワークフローファイルが多く初心者には結構なつまずきポイントとなりました。
混乱の元となるため基本的にはHCLのフォーマットで書かれた資料は極力参照しないほうが良いかと思います。

Actionの種類はJavaScriptベースのそれとdockerベースのそれがある

大体はTravisやCircleCIと同じGithub ActionsですがActionの部分だけはそれらと大きく違います。
特にActionにはJavaScriptベースのものとDockerベースのものがあり、それによってワークフローファイルの書き方も結構違う点は気をつけましょう。例えば以下の項目はDockerタイプでしか働きません。

• jobs.<job_id>.steps.with.args
• jobs.<job_id>.steps.with.entrypoint

基本的にはActionのREADMEに書いてあるはずです。

また、Dockerタイプのものはワークフロー実行の最初にまずイメージをビルドする必要があるため実行時間が結構伸びます。ですので同じ機能のActionが複数ある場合可能ならJavaScriptタイプを選ぶほうが良いです。

成功したCI実行はリトライできない 2020/05/26に再実行機能が実装されました！

これは地味な問題でした。github actionsでは失敗したワークフローは再実行できるものの成功したそれは再実行することができません。

失敗したワークフローは画面の右上に「Re-run all jobs」というボタンがあるのですが成功したワークフローではこのボタンが存在しないのでした。