gh と peco でリポジトリ一覧から選択して clone する

はじめに、雑な説明

gh は GitHub 関連の操作がとっても楽になる便利な CLI です。
peco は CUI 上でインタラクティブに候補から出力を選択できるツールです。

各種インストール

gh: https://github.com/cli/cli#installation

peco: https://github.com/peco/peco#installation

エイリアス

.giconfig ファイルに下記を追加します

[alias]
	peco = "!f(){ git peco-$1 ${@:2:($#-1)}; };f"
	peco-clone = "!f(){ gh repo list -L 100 $1 --json nameWithOwner --jq '.[].nameWithOwner' | peco | xargs -I % gh repo clone -u up % ${@:2:($#-1)};};f"

-u up オプションを付けているのは fork リポジトリの場合にデフォルトで upstream が remote に追加されますが、この名前だと gh pr create したときに push する remote を選択するときに upstream が第一候補になってミスりやすいからです

使い方

git peco clone srz-zumix

最後に

今まで git clone するときにいちいち GitHub をブラウザで開いて URL コピペしたりして clone してましたが、gh の登場でかなり簡単に clone できるようになりました。

gh repo clone owner/repo

こうですね。

ただ、新しい PC に引っ越ししたときに環境構築をしていて、↑の方法で clone してたのですが、リポジトリ名なんだっけ？となることがあって（１つの org にいっぱい repo あったりするので・・）、その度にブラウザ開くか、「gh repo list owner」コマンドでリスト出してたんですが、 peco でワンオペにしたらええやんということで生まれました。

この方法であれば owner/organization 名さえ覚えておけば簡単に clone できます。
peco の機能で検索フィルタも書けられるので目当ての repo も探しやすい！

ちなみに GitHub Enterprise の場合は GH_HOST 環境変数でホストを指定すれば対応できますが、私はめんどくさいしつけ忘れてしまうことが多いので gh-do もインストールして下記のエイリアスを登録して使ってます。

alias ghe-do="gh do --hostname=github.hoge.jp --"

e.g.

ghe-do git peco clone xxx

今回は以上です。

【GitHub Actions】Organization/Owner 配下にあるすべてのリポジトリをマトリックスにする

https://github.com/srz-zumix/github-actions-sample/blob/main/.github/workflows/owner_all_repo_matrix.yaml

name: Organization/Owner repo matrix
on:
  pull_request:

permissions:
  contents: read

env:
  GH_TOKEN: ${{ github.token }}

jobs:
  prepare:
    runs-on: ubuntu-latest
    outputs:
      repos: ${{ steps.get-repos.outputs.repos }}
    env:
      TARGET_OWNER: srz-zumix
    steps:
      - id: get-repos
        run: |
            # shellcheck disable=SC2016
            REPOS=$(gh repo list "${TARGET_OWNER}" --json nameWithOwner --template '[ {{ range $i, $e := .}}{{ if ne $i 0 }}, {{ end }}"{{ $e.nameWithOwner }}"{{ end }} ]')
            echo "repos=${REPOS}" >> "${GITHUB_OUTPUT}"
      - run: echo "${{ steps.get-repos.outputs.repos }}"

  main:
    runs-on: ubuntu-latest
    needs: prepare
    strategy:
      matrix:
        repo: "${{ fromJSON(needs.prepare.outputs.repos) }}"
    steps:
      - run: echo ${{ matrix.repo }} 

gh repo list でリポジトリをリストアップして、その結果を --template で json の配列に整形。
fromJSON で matrix にセットします。

gh 使うとこういったことが楽に実現できるので便利です。

今回は以上です。

【GitHub Actions】【reusable workflow / composite action】Enable Debug logging したときだけコンテキストをダンプする step を仕込む

 GitHub Actions の共通アクションやワークフローを書いていると、たまに失敗したときの状態をより詳しく知りたいことがあります。
今回はその一例として github コンテキストなど、GitHub Actions から提供されるコンテキストのデバッグログを仕込みたいと思います。

ところで GitHub Actions の VSCode 拡張が公式からリリースされました。
実はこれを使うとコンテキストやワークフローの候補が出るようになるので、大変便利になりました。
これによって、いちいちこのコンテキストからは何が参照できるんだっけな？と調べる必要が減りました。
※ event の詳細は 2023/4 時点では候補にでなかったので、まだまだ event の詳細は公式ドキュメント（webhook のドキュメントですが同じものが入ります）や実挙動を見て確認する必要がありそうです

ワークフローを書いてる最中はどういう変数があるかはわかりますが、実際にどのような値が入ってくるのかはドキュメントなどから想像するしかありません。
ローカル環境でワークフローを実行する nektos/act のようなツールもありますが、これらは非公式かつ挙動が完全一致するものではないので、実際にワークフローを動かして確認するのが現時点では一番確実です。

私は act の gh 拡張機能（gh-act）を開発しており、その動作確認をこめてコンテキストをダンプしてるので参考にしてみてください。

さて、ワークフローを開発している最中や、リポジトリ専用のワークフローであれば、なにか失敗したときの調査に役立ちますし、常にコンテキストをダンプする step を置いておけば良いかなと思ってます。（実際にそうしてることが多いです）

こんな感じです

    steps:
    - name: $github
      env:
        GITHUB_CONTEXT: ${{ toJson(github) }}
      run: |
        echo "${GITHUB_CONTEXT}"
  

一方、reusable workflow など共通化して多数のリポジトリから使用されるものの場合、機能とは関係のないダンプはいれづらいです。（気にしなくていいとも思ったりもしますが、なんか個人的には避けたかった）

GitHub Actions はワークフローが失敗したときにデバッグログを有効にして re-run できます。理想としてはデバッグログとしてダンプできたらいいなと思っておりました。

reusable workflow 側でデバッグログを有効にされていることをなんらかの方法で判別できればよかったのですが、環境変数やコンテキストでは判別できなさそうでした。
ただ、デバッグログを有効にした場合、最初に紹介した $github ステップの env の設定がダンプされていることに気づきました。

こんな感じ

そしてこの env の評価ですが、 if: false のように常に実行しないステップにしても評価はされました。

先程と同じ用に見えますが、前者は ✔ マークアイコンですが、後者は / マークでスキップされていることがわかります。

ここでようやく結論、タイトル回収です。
「if: false で常に実行しないステップを用意し、知りたい情報を env にセットしておく」
こうすることでデバッグログを有効にしたときだけ github コンテキストの内容を確認できました。この方法は github コンテキストに限らず使えます。


今回は以上です。