対象の読者

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

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

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

CIの実行状況やログがウェブ上で確認できる点も同じです。
以下のようにCIステータス確認用の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サービスにおけるステータスバッジとはこれです。

僕はこれがとても好きなんですが現在のGithub Actionsが生成してくれるバッジのコードは微妙にイケてないです。

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)

2021/10/18 期待通りの文字列生成に改善されていることを確認！

今日ステータスバッジを生成したところ、こうあってほしいと書いたとおりリンクとして生成されるようになっていました

落とし穴

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」というボタンがあるのですが成功したワークフローではこのボタンが存在しないのでした。

多くの場合選択されるであろうPERFORMANCEプランの想定 ↩
Features • GitHub Actions ↩

Github Actions 2年使ってみてわかったことまとめ