自動化

毎週同じ手順でファイルを集計する、記事を書いたらサイトを作り直して公開する、毎朝決まった時刻に外部のデータを取りに行く。こうした定型作業は、一度手順が固まってしまえば、人がやる必要はあまりない。GitHub Actions は、そういう作業を GitHub のリポジトリに置いた設定ファイルひとつで機械に任せられる仕組みだ。 ただ、使い始めの段階でつまずきやすいのは、YAML の書き方よりも「いつ動かすか」の決め方だと思う。GitHub Actions には、コードを push したときに動かす方法と、決まった時刻に動かす方法がある。どちらも同じファイルに書けて見た目はよく似ているのに、動く条件も、どのコードを使うかも、失敗のしかたも違う。ここを混ぜたまま作り始めると、「動くはずの時刻に動かない」「同じ処理が二重に走る」といった、原因の分かりにくい不具合に出会うことになる。 この記事では、push 起点と定時実行の違いをはっきりさせたうえで、手動で動かす方法と権限の書き方を加え、最初のワークフローを1本置くところまでを順に見ていく。 GitHub Actionsは、リポジトリに置く「段取り表」 手元で何度も繰り返している手順は、そのままワークフローの材料になるPhoto: Joonspoon / CC BY-SA 4.0 GitHub Actions は、2018年10月に GitHub のイベントで発表され、2019年11月に誰でも使える正式版になった。もともとはテストやビルドを自動で回す道具として広まったが、中身は「きっかけが起きたら、用意した機械の上で決めた手順を実行する」という汎用の仕組みなので、開発とは関係の薄い定型作業にもそのまま使える。 設定はリポジトリの .github/workflows/ というフォルダーに置く YAML ファイルで書き、この1ファイルを「ワークフロー」と呼ぶ。ワークフローの中身は大きく三つに分かれていて、on に動き出すきっかけを書き、jobs に実行する仕事の単位を書き、各ジョブの steps に具体的な手順を上から順に並べる。手順には、自分で書いたコマンドを run で実行するものと、ほかの人が用意した部品(アクション)を uses で呼び出すものの二種類がある。 ジョブが実際に動くのは、GitHub が用意する使い捨ての仮想マシンの上だ。これを「ランナー」と呼び、runs-on: ubuntu-latest のように OS を指定する。ランナーは毎回まっさらな状態で起動し、ジョブが終われば消える。前回の実行で作ったファイルは残らないので、必要なものは毎回リポジトリから取り出し、結果は保存先へ書き出す、という前提で手順を組むことになる。 料金の面では、公開リポジトリなら標準のランナーは無料で使える。非公開リポジトリでも、無料プランで月2,000分までの実行時間が含まれている。1回数十秒で終わる定型作業なら、毎日動かしても枠を使い切ることはまずないと思う。 push起点は「変わったときだけ」動く まず push 起点のほうから見ていく。on: push と書いたワークフローは、そのリポジトリにコミットが push されるたびに動く。このブログの本家も、記事を書いて main ブランチに push すると、サイトを組み立てて公開するワークフローが走る仕組みになっている。 push 起点のよいところは、作業の結果と実行のきっかけが一対一で結びついている点だ。どのコミットで動いたのかがはっきりしていて、ワークフローは push されたそのコミットの中身を使って実行される。失敗したときも、直前に何を変えたかを見れば原因の見当がつきやすい。 そのままだと、README の誤字を直しただけでも重い処理が走ってしまうので、条件を絞るのが普通だ。 on: push: branches: [main] paths: - 'content/**' - 'static/**' branches で対象のブランチを、paths で対象のファイルの場所を指定すると、条件に合う変更が含まれる push のときだけ動く。逆に、特定の場所の変更だけを除外したいなら paths-ignore を使う。ただし同じきっかけに paths と paths-ignore を両方書くことはできないので、どちらか一方に寄せて考える。 ...