branchをmergeしてからテストしてリリースする、という流れで開発からリリースまでのサイクルを回している。Actionsで自動化できないかと思い、実際やってみたところ意外と簡単にできたので、そこで得られた知識をこの記事にまとめる実際のコードと説明それでは実際のactionsのYAMLファイルをもとに細かく説明する。今回使用したYAMLファイルはここにあがっている。このYAMLに定義するべきものがonである。これはワークフローを実行するためのトリガーの定義である。今回の例だと以下のように、releaseがpublish(公開)されたらワークフローを動かすようにしている。branchにpushされたら、pull-requestが作成されたらなどをトリガーすることができる。詳細は以下の公式ドキュメントで詳しく説明されている。Helpjobsで実行する処理を定義するjobsの下に行いたい処理の名前(job_id)を書いて、その下に行いたい処理を記述していく。コマンドをshellで実行する。actions/checkout@v2環境変数のセット何かしら計算した結果を保存して、次のstepで参照できるようにしたいことがある。いう場合は環境変数をセットする。$NEXT_VERSION)"例えば上記のコードは以下の処理を行っている。GITHUB_REFにあるタグの値(refs/tags/0.1.0)を取得そこからバージョン部分を抜き出してCURRENT_VERSIONにセットperlで次のバージョンにインクリメントしてNEXT_VERSIONにセット::set-envを使って環境変数NEXT_VERSIONをセット構文が気持ち悪いが、set-envを使うことで環境変数をセットすることができ、後続のstepで参照することができる。TBD"上記のコードはpull-requestを作る例だが、GitHub上のリポジトリに対して何か操作を行う場合はGitHubのTokenが必要になる。定義されているGITHUB_TOKENを使用する。secretsはリポジトリの設定画面から自分で値をセットすることもできるので、秘匿したい文字列などはsecretsを通してstep内で使用するのが良い。Actionsの良いところは、デフォルトのsecretsとしてGITHUB_TOKENが定義されていて、GitHubのリポジトリに対して操作を行う場合はTokenのことを気にする必要がないことだと思う。ActionsのYAMLでは式を書くことができる。}}の中には式を書くことができる。ようなあらかじめ定義されているcontextsが使える。他にどのようなcontextsがあるかはドキュメントを読むと良い。定義されたfunctionsがあり、expressionの部分で呼び出すことが可能である。GitHubを見るとたくさんのActionがあることがわかると思う。他の人が作った汎用的なActionがたくさん転がっているので、これを見ているだけでも「ああこんなこともできるのか」と参考になるし、いろいろ組み合わせて面倒な作業を自動化することができる。Actionsはとてもオススメ。