GitHub

コードを書いているのはエディターとターミナルなのに、プルリクエストを出すときだけブラウザに移る。タブを探し、リポジトリのページを開き、「Compare & pull request」のボタンを押し、タイトルと説明を書き直し、レビューをお願いする相手を選ぶ。一つひとつは数十秒の作業でも、1日に何度も繰り返すと、そのたびに頭の中で組み立てていた続きが途切れてしまう。私が気になっていたのは、時間そのものより、この途切れのほうだった。 GitHub CLI、コマンド名で言えば gh は、GitHub が公式に配布しているコマンドラインの道具だ。git が手元のリポジトリと遠くのリポジトリのあいだで履歴をやり取りする道具だとすれば、gh はその外側にある GitHub 独自の仕組み、つまりプルリクエスト、イシュー、Actions の実行結果、リリースといったものをターミナルから扱うための道具になる。git の代わりではなく、git の隣に置いて使う。 この記事では、朝にブランチを切ってプルリクエストを出し、昼に CI の結果を待ち、午後にレビューをやり取りして、夕方にマージするまでの一日を、gh のコマンドだけでたどっていく。最後に、毎日使うための短縮の設定と、それでもブラウザを開いたほうが早い場面もまとめておく。 準備はインストールとログインの2つだけ エディターの隣にターミナルを置いておけば、プルリクエストの操作もそこで済むPhoto: Wikideas1 / CC0 インストールは、Windows なら winget install --id GitHub.cli、macOS なら brew install gh の1行で終わる。Linux でも主要なディストリビューション向けのパッケージが用意されている。入れ終わったら gh --version で版を確かめておく。gh は数週間おきに新しい版が出るので、手順の説明と手元の動きが違うと感じたら、まず版を新しくするのが近道だと思う。 次にログインする。gh auth login を実行すると、どの GitHub につなぐか、git の通信に HTTPS と SSH のどちらを使うかを順に聞かれる。認証の方法は、ブラウザでの承認を選ぶのが手軽だ。ターミナルに8文字の確認コードが表示され、ブラウザで GitHub の承認画面を開いてそのコードを入れると、ログインが完了する。ブラウザを使うのはこの一度だけで、受け取った認証情報は OS の資格情報の保管場所にしまわれる。 ログインできたかどうかは gh auth status で確かめられる。どのアカウントで、どこに認証情報が置かれているかが表示される。あわせて gh auth setup-git を一度実行しておくと、git の push や pull でも gh の認証情報が使われるようになり、パスワードやトークンを毎回聞かれることがなくなる。サーバーや自動化の仕組みの中で使うときは、ログインの代わりに環境変数 GH_TOKEN にトークンを入れておけば、gh はそれを読んで動く。 ...

毎週同じ手順でファイルを集計する、記事を書いたらサイトを作り直して公開する、毎朝決まった時刻に外部のデータを取りに行く。こうした定型作業は、一度手順が固まってしまえば、人がやる必要はあまりない。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 を両方書くことはできないので、どちらか一方に寄せて考える。 ...