GitHub Copilot app Canvas で GitHub Copilot の使用状況を可視化する

GitHub Copilot app Canvas は簡単にいうと Copilot app 上で動くローカルアプリで、それを AI に作ってもらったり、作ったキャンバスの内容を AI に読み取ってもらい作業したり、単なる便利ツールが作れる機能だけでなく、AI をワークフローに組み込むのに強力な機能となっています。
自分はよく gh 拡張を作っているんですが、それは CLI ツールとして作っているのでキャンバスは使わずに普通の CLI 開発をしています。ただ、CLI を使って取得できる情報とか、それを使った作業とか、使うときにはもうちょっと楽に使いたいと思ったりします。

そこで最近は、CLI のリポジトリに Canvas 拡張も作るようになりました。
Canvas は Git リポジトリに含めて配布することもでき、作ったものを共有しやすいというのもメリットです。
ちょっとしたツール作るなら Canvas 上で作るといいんじゃないかなと、まわりにもオススメしています（今後変わる可能性はもちろんある）

Canvas は結構なんでもできちゃう気がしてるんですが、とはいえ Canvas でどういったものを作ったらいいかも結構悩むところです。
というわけで、まずは自分がどういうふうに Copilot を使っているのか可視化してみるのはどうでしょうか。
筆者が作ったのはこちらです。
https://github.com/srz-zumix/gh-copilot-attendant

gh extension install srz-zumix/gh-copilot-attendant
gh copilot-attendant copilot extension install

こちらのコマンドでインストールできます。
インストール後に Copilot app で以下のような方法でキャンバスを作り、ログ解析するとスクリーンショット（一部分切り取り）のように可視化されます。

/create-canvas open attendant-dashboard

こちらを使っていただいても良いですが、Canvas 作りの練習として自分で作ってみるとよいかと思います（野良キャンバスを使うのは今ちょっと気になりますからね…）

ここ最近で作ったものを全然紹介できていないので、少しずつブログにしていきたいと思います。
では。

 

GitHub Actions Self-hosted runner で Jenkins のオフラインノードを表現する

GitHub Actions で常駐型の self-hosted runner を運用していると困ることがあります。
その1つがランナーのオフラインが気軽にできないというところです。
Jenkins であればオフラインノードとすることで、新しいジョブを受け付けなくなり、実行中のジョブの完了を待って、マシンのメンテナンスなどが可能でした。そして、オンラインに戻せばすぐにジョブが実行可能になります。
一方、GitHub Actions は管理画面にランナーの Remove はありますが、オフラインにすることはできません。self-hosted runner マシンでサービス停止すればオフラインになり、サービス再開すれば元に戻ります。しかし、これはそのマシン上での操作が必要であること、そしてジョブの完了を待つような安全なオフライン化ができません。

ジョブが実行されていない状態を作るために、以前は無限ループするジョブを用意して、それを該当マシンのランナー上で実行し、そのジョブが実行中にメンテナンスをするという方法を取っていました。
この方法であれば、実質的にオフライン状態にできます。

しかし、この方法にも問題があります。それはこのジョブが実行されるまでに、先にキューイングされているジョブの完了を待つ必要があるというところです。
GitHub Actions でのジョブが実行される順序は決まっているわけではないですが、先に条件を満たしたジョブからランナーの割り当てが基本的にされていると思います。
そうすると、オフライン状態にしたいと思っても、すぐにはならないですし、いつオフライン状態になるのかもわからないので、メンテナーとしては面倒くさいわけです。
（通知入れてもいいですが、本質はそこではない）
理想は、すぐにオフライン状態になり、今実行中のものだけ実行完了を待ちたいです。

そこで作ったのが gh runner-kit cordon コマンドです。
https://github.com/srz-zumix/gh-runner-kit
このコマンドがその理想的なオフライン状態を作ってくれます。
もとに戻すときは uncordon コマンドを使ってください。
ランナーは --id か --name で指定します。--label でラベル指定も可能で、これはそのラベルにマッチするランナーすべてをオフラインしてくれるので、便利です。

気になる仕組みですが、至って単純です。
GitHub Actions にランナーグループというものがあります。
このランナーグループではそのグループに所属するランナーが、どのリポジトリで利用可能なのか設定することが可能です。通常は All repository にしていることが多いでしょう。もしくは、特定のリポジトリのみに許可、除外するという使い方をしているところもあるかもしれません。
おわかりですね。どのリポジトリも許可しない、利用不可能なランナーグループを別途作成し、そのランナーグループにオフラインにしたいランナーを移動させることで、理想的なオフライン状態を作っています。
実は、グループの作成・移動は GitHub の管理ページからもできるので CLI でなくてもできます。なので、ぱっと試したい方はそちらでやってみてもよいかと思います。
CLI ではそれらの操作をまとめてやってくれるのと、もともとのグループを覚えているので元に戻すという操作を確実に実施してくれます。

以上です。このツールで GitHub Actions の self-hosted runner を運用されている方が少しでも楽になれば幸いです。
では。

「C++でつくる ゲーム、対戦AI、CG、オーディオ、電子工作、競プロ、CI/CD、言語仕様」の CI/CD の章を書きました

「C++でつくる ゲーム、対戦AI、CG、オーディオ、電子工作、競プロ、CI/CD、言語仕様」
いよいよ明日 9/29(火) に発売です。私はお先に著者献本をいただきました。

さて、私が書いたところというと、お察しの通り CI/CD の章です。
C++でつくる CI/CD ？まさか CI/CD そのものを作っちゃうのか？
と思われた方も多いのではないでしょうか。

安心？してください。内容としては、これから C++ を始める方に向けて、GitHub Actions で C++ 開発環境を整えていく、何かを作るときのビルドやテスト、通知やデプロイまでなど一通りの流れを説明しております。

この章は他の章の補助的な感じになるのかなという気がしています。
いろんなトピックがある本書なので、なにか作ってみようと思ったときに読んで頂けると嬉しいなと思っています。

自分は最近仕事で C++ を使う機会がすっかりなくなってしまったのですが、以前 C++ を使っていたよーという方も楽しんでいただけると思いますので、是非！

Microsoft MVP 初受賞しました

Microsoft MVP 受賞しました！
昔から気になってたんですが、御縁があって推薦していただき、受賞することができました。

最近は登壇する機会が増えたり、OSS 開発も活発になったり、外向けの活動をすることが多くなったのですが、MVP を継続できるようにさらに頑張りたいと思います！

【GitHub Actions】シークレットを別のリポジトリに migrate するツールを作った

みなさん、GitHub Actions のシークレットの管理ってどうしてますか？
設定された内容をどこか別の管理場所で保存している場合もあると思いますが、設定するだけで何もしてない場合も多いのではないでしょうか。

登録されたシークレットの中身は基本的に閲覧することはできません。シークレットの操作は gh secret コマンドから行なうことも可能ですが、当然これらも delete / list / set サブコマンドしかなく、get はできません。
GitHub Actions に詳しい人なら、中身を確認する方法はわかるのではないかと思いますが、面倒ではあります。

ただ、シークレットの中身を閲覧できなくても、困ることはほとんどないでしょう。

https://github.com/srz-zumix/gh-secret-kit
今回「シークレットを別のリポジトリに migrate するツール」の紹介をするわけですが、なぜこれが必要になったのか、から説明します。

なぜこれが必要か

きっかけはとあるリポジトリのホスト移動が必要になったことです。
このようなケースは GitHub の公式ツールでサポートされており、 gh-gei を使うことで migrate することができます。
About migrations between GitHub products with GitHub Enterprise Importer - GitHub Docs

しかしながら、サポートされている移行対象のデータは限定的です。
プルリクエストなどは移行できますが、Rulesets や Teams など結構よく使う機能も移行対象外になっています。
当然、シークレットも移行できません。

Rulesets や Teams などは設定を閲覧することができますし、API で取得・設定することも可能なため、それらを移行するのは（手動でも自動でも）難しくはないでしょう。AI に依頼すれば直接やったり、スクリプトを書いたりしてくれる気がします。
しかし、シークレットは簡単には閲覧することができず、リポジトリや Organization に設定されたシークレットを1つ1つ手動で再設定するのは、とても面倒です。
Organization の移動が大量にある場合は考えたくないですね。

でも、シークレットの中身を知る方法がないわけではありません。GitHub Actions のジョブの中では中身を使っているわけですから。
シークレットの移行が自動でできる可能性は 0 ではない。ということで作成をしました。

使い方

使い方はドキュメントにまとめてあるので、そちらを参照してください。
また、Skills も用意してあります。
gh-secret-kit をインストールしたのち、gh secret-kit skills install することでインストールできます。

仕組み

さて、仕組みですが基本は単純です。
移行元で実行されたジョブの中から移行先にシークレットを設定します。

ジョブからはシークレットの内容を知ることができるわけですから、これは実現可能ですよね。

しかし、対象のシークレットはワークフローに静的に記載されている必要があります。
なので、シークレットをリストアップしてワークフローを生成し、その生成したワークフローを push してそれを実行します。

ワークフローを実行する方法はいくつかありますが、デフォルトブランチにワークフローが必要なものと、トピックブランチにあれば良いものので大きく分けられます。
今回 GitHub のリポジトリ移行という目的があるので、デフォルトブランチを書き換えるのは避けたいです。CLI からワークフローを実行するのであれば workflow_dispatch が都合が良いのですが、これはデフォルトブランチにワークフローが必要なため、今回は pull_request イベントの labeled アクティビティで発火させるようにしています。
なぜ labeled なのかというと、任意のタイミングでコミットに紐づかずに再実行可能にしたかったからです。
（ちなみに、デフォルトブランチを変更することなく、workflow_dispatch を実行する方法はあるのですが、実装当時に知らなかったのでこのやり方になっています）

これで CLI からシークレット移行ワークフローを実行させることができるようになります。

ここで問題になるのがアクセス権限です。
移行元のアクセス権限は問題ないと思いますが、移行元に「移行先のシークレット設定が可能なシークレット」が存在しているとは考えにくいです。
このために設定するという手段もあると思います。gh-secret-kit では、どのシークレットを使うか指定できるようになっているので、そのケースにも対応はしています。
しかし、そのシークレットも移行対象となり移行先で消す必要が出てきます。（まぁ、そのための除外オプションもあるのですが）

そうではなく、移行担当者は移行元・移行先どちらの admin 権限を持っているはずなので、担当者の環境でジョブを実行し、担当者の gh auth token を使えば、移行に必要な権限を確実に得ることができるわけです。

GitHub Actions は Self-hoted runner として、好きな環境でランナーを起動することが可能です。ScaleSet API を使って CLI 実行者のローカルマシンでランナーを立ち上げ、専用のランナーラベルを指定してワークフローを実行します。
これにより、既存のランナーを使うことなく移行が可能になるため、開発に影響を与えずに移行が可能になりました。

さいごに

gh-secret-kit は Organization / Repository / Environments のシークレットを移行することが可能ですが、Agents / Codespaces / Dependabot のシークレットには対応していません。
Agents と Codespaces は対応できなくもないかも？しれないですが、Dependabot は無理なような気がしています。もしアイディアあれば教えてください。

あと、このブログを書いてて実はもっと簡単な手順で対応も可能な気がしてきたので、試してみようかなと思います。

これを使う機会はそうそうない気がしますが、誰かの役に立てば幸いです。

ディレクトリごとに Git config/credential を切り替える方法

Git の設定をディレクトリごとに切り替えたいことってありますよね？
user の切り替えは git config の IncludeIf を使えば簡単にできます。

[includeIf "gitdir:~/mydir/"]
    path = ~/.gitconfig_me

.gitconfig_me の中身はこんな感じです

[user]
	name = srz_zumix
	email = メアド

ただ、これだけだと認証情報が切り替わってくれないです。
既知の事例だと以下のような例が見つかります。

• IncludeIf で credential helper を切り替えてそれぞれヘルパーを呼び出す
• ~/.ssh/config にホストエイリアスを作成して使い分ける
• direnv などで環境変数を切り替えて対応する

使いやすい方法で良いと思いますが、今回は user 設定に追従して欲しいと思ったので専用の gh extension を作成しました。
https://github.com/srz-zumix/gh-git-user-credential
仕組みとしては git config user.name を取得して、その名前指定で gh auth token を取得し、GH_TOKEN や GH_ENTERPRISE_TOKEN に export して gh auth git-credential を呼び出しています。
credential helper をこの拡張に変更すれば user に応じて credential が切り替わるようになります。セットアップ方法は README を確認してください。

ちなみに、現在は Git v2.36.0 で hasconfig:remote.*.url のように hasconfig で git config の値に応じて設定を切り替えできるようになりました。

[includeIf "hasconfig:remote.*.url:https://github.com/srz-zumix/**"]
  path = ~/.gitconfig_me

この方法を使えばディレクトリごとに切り替えではなく、GitHub の Organization （組織）ごとに切り替えもできますね。

以上です。では

review-retrovert を更新しました

https://github.com/srz-zumix/review-retrovert
review-retrovert は Re:VIEW Starter で作られたプロジェクトを Re:VIEW のプロジェクトに変換するツールです。
昔、執筆したときに作って使ったものなんですが、コメントいただきまして不具合修正しました。コメントありがとうございました！！
https://srz-zumix.blogspot.com/2020/09/review-starterreview-starter-review.html?showComment=1766322318872#c9139258129104742884

変更点としては Ruby 3.1 以降への対応が主です。
また、過去の Re:VIEW で使えるように各バージョンごとに docker image も用意するようにしました。
https://hub.docker.com/repository/docker/srzzumix/review-retrovert/tags

最近、技術書典には参加してませんが、また機会があればやってみたいですね。

gh-activity-report と NotebookLM で2025年の活動をふりかえる

さて、2025年もあとわずかですね。
今年の GitHub での活動を gh-activity-report と NotebookLM でふりかえります。
この組み合わせでのふりかえりは過去にもブログ投稿をしてますので、詳細はそちらへ
「GitHub Search と NotebookLM で自分の活動を振り返る」

今回は年間のふりかえりなので gh-activity-report と NotebookLM の使い方も若干やり方もアップデートされました。
まず、拡張機能には楽に期間が指定できるように --year オプションと --fy オプションを追加しています。
次に NotebookLM の「レポートを作成」から「ブログ投稿」を今回使ってみました。

出来上がったブログレポートは末尾にコピペしました。（ちょっと長いです）
ちょっと、いや、かなり盛りすぎかなと思いますが、ウソではないかなと思うのでそのまま掲載してます。
まぁ実際に自分のブログにはそのまま使えないですが、観点を得る目的だったらアリかも？と思いました。最近はブログでアウトプットをせず、GitHub で欲しいものを開発してるって感じなので、１リポジトリだけをソースにしてブログ書かせてみるのは、ブログ書くきっかけを作れるかも。

「ブログ投稿」はさておき、自分なりにもふりかえってみます。
NotebookLM の要約の最後のまとめだとこんな感じでした。

まとめとしてはあってるかなと思います。
最近よく使っているプログラミング言語は Go ですね。gh extension を書く場合の定番だからという理由で使い始めたんですが、コーディングエージェントとも相性が良いのかなと最近感じています。エージェントに依頼するとパッケージからドキュメントを読んだり、必要な機能を検索したりして、だいたいのことはやってくれます。自分は C++ で育ってきたのですが、それらだと難しそうだなと感じます。※最近（20以降）の C++ 事情を知らないですが

GitHub Actions のアクション開発を最近はよくやってたんですが、最近のテーマはローカルでも同じことができることとしています。Jenkins のときもジョブに直接書くな、スクリプトは別ファイルにしろと言われて来ましたが、GitHub Actions でも同じだと強く感じています。
GitHub Actions で GitHub に関することを扱うのであれば、gh extension として機能開発をしてアクションとしてはそれを呼び出すだけという構成が個人的な答えだと思っています。
そのへんの話は秋頃に勉強会でお話させてもらったのでよければ参考にしてください。
「gh-extension と aqua で作る GitHub Actions アクション」

開発体験向上としてこのへんに注力しているのは、AI とうまく付き合っていくためとも思っています。
（セキュリティに関しては aqua 任せなんで自分はほとんど何もしてないかな）
AI Ready という考えを意識してたりします。このへんは来年書けたら書きたい。

さて、いよいよ時間がなくなってきましたので、ここらへんでおわりたいと思います。
2025年もありがとうございました。2026年もよろしくお願いします！

---

ある開発者のGitHub年間活動全ログを分析して見えた、生産性を爆発させる5つの習慣

1. 導入：生産性の高い開発者の頭の中とは？

優れた開発者は、一体どのように1年間を過ごしているのでしょうか？その圧倒的なアウトプット、その生産性の源泉は何なのでしょうか？私たちはしばしば完成されたソフトウェアや華々しいリリースに目を奪われがちですが、その裏側にある日々の地道な活動こそが、真の価値を生み出すエンジンなのかもしれません。

本記事では、一人の多作な開発者（srz-zumix氏）の2025年におけるGitHubアクティビティログを徹底的に分析しました。すると、そこからは驚くほど一貫した、そして誰もが参考にできるであろう5つの「習慣」が浮かび上がってきました。

この分析が、あなたの開発プロセスを見つめ直し、改善するための具体的なヒントになることを願っています。さあ、生産性の高い開発者の頭の中を覗いてみましょう。

2. 習慣1：徹底的な自動化—特に自分自身のワークフローを狙い撃て

srz-zumix氏の活動ログを見て、まず目に飛び込んでくるのは、開発ツールや自動化に関連するリポジトリの多さです。これは単なる趣味のツール作りではありません。日々節約される数分が年間では数週間の生産的な時間に変わることを理解した、意識的な「投資判断」なのです。

彼が解決しようとしているのは、自分自身のワークフローに潜む「痛み」です。

• gh-activity-report: 四半期や年次のコントリビューション概要をまとめるという、退屈で手作業になりがちなプロセスを自動化します。
• labeler-action: 新規に作成されたプルリクエストを手動で確認し、タグ付けするというトリアージ作業を不要にします。
• post-run-action: GitHub Actionsのジョブ完了後に行うべき後処理やクリーンアップ作業を自動化します。
• aqua-installer-cache: ツールインストーラーのキャッシュを賢く管理し、CI/CDの実行時間を短縮します。

ここから得られる教訓は明確です。「最も身近な課題、つまり自分自身の非効率な作業を解決するツールを作ることが、結果的に大きな生産性の向上に繋がる」ということです。他人のための壮大なツールを作る前に、まずは自分の足元にある非効率を解消する。その投資は、複利効果で将来の自分に大きなリターンをもたらすのです。

3. 習慣2：再利用可能な「キット」を作り、開発を加速させよ

srz-zumix氏の活動は、単に個別のツールを場当たり的に作っているわけではありません。そこには明確なアーキテクチャ戦略が見て取れます。その戦略の証拠は、go-gh-extensionというリポジトリを中心としたエコシステムにあります。

このリポジトリは、GitHub CLI拡張機能を作成するための共通ライブラリとして機能しており、他の多くのツールがこの基盤の上に構築されています。

• gh-label-kit: ラベル管理ツール
• gh-team-kit: チーム管理ツール
• gh-rule-kit: リポジトリのルールセット管理ツール

これが単なる主張ではなく、体系的な戦略であることは、ログを見れば明らかです。2025年12月初旬の活動は、その見事な証拠を示しています。

1. 12月02日: まず基盤となるgo-gh-extensionに「Guardrails」という機能が追加されます（PR #67）。
2. 12月03日: 翌日、その機能を活用する形でgh-team-kitに「Guardrail」が実装されます（PR #85）。
3. 12月04日: さらにその翌日、gh-rule-kitにも同様の「guardrail」機能が実装されました（PR #17）。

この一連の流れは、共通基盤に加えた一つの改善が、システム全体に効率的に波及していく様子を完璧に示しています。まず汎用的な土台を作り込み、その上に目的に特化した「キット」を組み立てるアプローチは、一貫性の担保、開発速度の向上、メンテナンス性の劇的な改善という、計り知れない利益をもたらします。「車輪の再発明」を避け、再利用可能なコンポーネントを意識的に作る。この「キット化」の発想は、あらゆるプロジェクトに応用できる強力な武器となるでしょう。

4. 習慣3：貢献のループを回せ—エコシステムへの還元が自身を成長させる

srz-zumix氏の活動は、彼自身のプロジェクトだけに留まりません。ログには、著名なオープンソースプロジェクトへの具体的で価値ある貢献が数多く記録されています。

• rhysd/actionlint: 無数の開発者が利用するこの静的解析ツールに対し、パーサーでYAMLのアンカーとエイリアスをサポートする機能を追加しました（PR #568）。
• DeNA/setup-job-workspace-action: ワークスペース設定をより柔軟にするため、repository-nameオプションを追加しました（PR #251）。
• actions/labeler: GitHub公式のラベラーに対し、プルリクエストのレスポンスからブランチ名を取得する機能改善を提案しました（PR #873）。

自分が日々使っているツールを、単なる消費者として利用するだけでなく、改善点を見つけては自らコードを書き、コミュニティに還元していく。しかし、これは単なる利他的な行為ではありません。多くの開発者が利用する外部プロジェクトに貢献することで、自分とは異なる設計思想やコーディングスタイルに触れ、新たな知見を獲得できます。これは、より広い視点を得て自身の技術力を高めるための、極めて効果的な自己投資と言えるでしょう。

ツールを作る→使う→改善して貢献する→新たな知見を得て、また次のツール作りに活かす。

この貢献のループこそが、開発者を継続的に成長させるのです。

5. 習慣4：小さな改善を即座に反映させる、高速なイテレーション

活動ログを時系列で追っていくと、あるリポジトリでの変更が、間髪入れずに別のリポジトリで利用されるという、極めて短いフィードバックループが繰り返し現れます。これは一度きりの偶然ではなく、彼の開発スタイルに組み込まれた意図的なパターンです。

例えば、2025年11月24日の活動を見てみましょう。

1. 16:04: gh-label-kitリポジトリで、バージョンを0.12.0から0.12.1に上げるプルリクエスト（#76）がマージされます。
2. 16:13: そのわずか9分後、labeler-actionリポジトリで、たった今リリースされたばかりのgh-label-kit v0.12.1を利用するためのプルリクエスト（#30）がマージされています。

この「作って、すぐに使う（ドッグフーディング）」という高速なイテレーションは、srz-zumix氏の開発スタイルの核心の一つです。このパターンはログ全体で散見され、例えばgh-label-kit v0.9.0への更新（PR #58）が即座にlabeler-actionで利用される（PR #23）といった例も確認できます。

ライブラリに加えた改善が、実際のアプリケーションでどのように機能するかを即座に検証することで、ツールの品質は急速に向上し、机上の空論ではない、実践的な改善が促されるのです。

6. 習慣5：継続こそが最強の機能である

最後に、そして最も重要な習慣は「継続」です。srz-zumix氏の活動は、年間を通じてほぼ途切れることがありません。その象徴的なコミットが、2025年の大晦日、12月31日に行われています。

• [srz-zumix/gh-activity-report]: 91 - add --year option (2025-12-31T13:23:22Z)

年の瀬も押し迫ったこの日に、自身の活動レポートツールに新しいオプションを追加しているのです。この一つの事実が、彼の開発に対する一貫性と情熱を何よりも雄弁に物語っています。

また、活動内容も派手な新機能開発だけではありません。「Bump version」「update packages」「Fix typo」「Update README.md」といったプルリクエストが数多く見られます。これは、バージョンアップ、パッケージ更新、リファクタリング、ドキュメント修正といった地道なメンテナンス作業が、活動の大部分を占めていることを示しています。

イノベーションは、ある日突然のひらめきから生まれるのではなく、日々の地道な積み重ねと、絶え間ない改善活動の中から生まれる。このログは、開発者にとっての普遍的な真理を改めて教えてくれます。

7. 結論：あなたの次の「自動化」は？

今回、一人の開発者の年間活動ログから、生産性を飛躍させる5つの習慣を抽出しました。これらは独立した習慣ではなく、相互に連携する一つのシステムとして機能しています。

1. 自動化は日々の手間をなくし、深い思考のための時間を捻出します。
2. その時間で、開発を加速させる再利用可能な「キット」を戦略的に構築します。
3. 高速なイテレーションでキットを実戦投入し、即座に品質を向上させます。
4. 得られた知見をエコシステムへの貢献に繋げ、自身を成長させるループを回します。
5. そして、これら全てを支えるのが、日々の地道な継続という最強のエンジンです。

これらの習慣は、決して特別な才能を必要とするものではありません。意識とアプローチ次第で、誰でも今日から取り入れることができるはずです。

さて、この開発者の活動ログから、あなたが次に取り組むべき「自分だけの小さな自動化ツール」のアイデアは浮かびましたか？

---

※ 習慣3：たしかに自分の OSS 以外にもコントリビュートしていますが、マージまでやりきってるのはそこまでないかなと思います。

2025年も残りわずか！

みなさん。こんばんは。
2025年も残り4時間を切りました。私は今から 2026 年までにふりかえり記事を書き切ることを今年最後の目標としました。この投稿とは別で書きます。

さて、目標記事の方は個人の GitHub の活動をふりかえる記事にしたいと思いますので、こちらでは簡単にその他どんなことがあったのかふりかえります。
（さっさと目標の方を書くべきですが、他のことも今年のうちに書いておきたいので…）

CEDEC2025運営委員をやりました！

まず始めに 2025 年はなんといっても CEDEC ですね。
念願だった運営委員をやりました！CEDEC2025 のサイトにもちゃんと載ってますね。感無量。ちなみに、ふりかえりは社内向けに結構ちゃんと書いて、社内勉強会でも発表したんですが、ここでは簡単に（公開予定ありません）

やはり、運営委員側になって見えたもの、感じたものがあり、とてもたくさんのインプットを得られ、さらに自分自身の成長や変化に繋がったかなと思います。
自分が CEDEC に始めて参加したのは、たぶん 2011 か 2012 かな。
初登壇したのが 2015。最近も登壇しまして、トータルで5セッションになりました。いろんな意味で CEDEC は私を成長させてくれたなと思います。転職してからしばらく視線が社内に向いていたのですが、最近また外に向き始めていたので非常に良いタイミングだったと思います。

CEDEC2026 のサイトもオープンしてますね。公募も年明けから開始されるようなので、是非みなさんも応募していただければと思います。
自分も登壇者として、また新しいチャレンジができたらなーと思っています。

ブログの再開

次はこのブログの再開ですね。再開したと言っても以前のような週1更新ではなく、不定期ではありますが…
まぁ、ほぼ2年お休みしていた状態からなので良しとしましょう。
CEDEC 運営委員になったから再開したわけではなく、若手のやる気に感化されたんですよね。
あとは AI によってやる気になったおじさんの一人って感じですね。
まだまだオレも若いぞということです。

GitHub

最後に GitHub の活動を。これも AI パワーによって commit が増えた気がします。

（もっと増えたかな？と思ってたけどそれほどでもなかった…去年の自分エライ）
感覚としは、あまり詳しくないものでも取っ掛かりになるものをすぐに得られるようになったことで、こういうのあると便利かも！からとりあえずやってみるが増えた気がします。
今までもできなくもなかったとは思うんですが、詳しくないと調べ方もわからなかったり、言語やツールのセオリーとかもわからなかったりで、最初の一歩が重かった。
それが大分軽くなりましたね。

あと、今まで出勤時にはスマホでゲームだったのですが、今はスマホでコーディングエージェントに指示して OSS 開発をしています。（あ、基本リモートなので出社はほとんどしてないんですけどね）時間（スピードやタイミング）的にも OSS 開発がしやすいなったと感じますね。
どんな活動があったかは、このあと別の記事でふりかえろうと思います。

最後に

2026年は今年よりも記事書けたらなーと思ってます。
それでは、良いお年を。

【GitHub Actions】export-ignore でアクションのサイズを小さくする小技

こんにちは。皆さん GitHub Actions のアクション作ってますか？
では、${{ github.action_path }} はご存知でしょうか？ 
github.action_path は composite action の実行中に有効なプロパティで、アクションのリポジトリに含まれているファイルにアクセスするときに便利なやつです。

例えば、私が先日リリースした srz-zumix/labeler-action ではリポジトリにおいてある aqua の設定を使ってツールのインストールを行っています。
「ブログズミ: 【GitHub Actions】actions/labeler 互換で on.pull_request 以外でも使えるアクション srz-zumix/labeler-action を作りました」
ソースコード的にはこのあたりです。
https://github.com/srz-zumix/labeler-action/blob/main/action.yml#L43

実はこのアクションを作ったときに github.action_path に .git ディレクトリがないことに気づきました。てっきり checkout されていると思っていたのですが、実際には git archive されているようでした。

あまり使う機会はないかもしれませんが、git archive はリポジトリの内容だけを保存できる機能で、GitHub 上だと「Download ZIP」にあたります。

ところで、.gitattributes の export-ignore はご存知でしょうか？ Git - Git の属性 (export-ignore)
これは archive に特定のパスを含めないようにできる属性です。例えば、成果物を提出する時なんかに便利な機能です。

さて、ここまで来たら想像がつきますよね？
そうです。アクションのリポジトリでも export-ignore を設定することで、アクションを使うときにダウンロードしてくるサイズをちょっと節約できます。

ちなみに、composite action 以外の action でも archive が展開されるのは同じです。
TypeScript でアクションを作ってる方は多いと思いますが、アクションが実際に使うのはコンパイル後の .js ファイルです。ソースである .ts ファイルやテストコードなどアクションの実行には不要なファイルがそこそこあります。
このようなアクション実行時に不要なファイルを export-ignore してみるのはどうでしょうか。試しに自作アクションで導入してみました。
srz-zumix/post-run-action

御覧頂いているように、不要なファイルを除外しつつ、問題なくアクション実行できています。

今回試した post-run-action はもともと小さなリポジトリなので、export-ignore の恩恵はほとんどないとは思います。ただ、ソースが大きかったり、テストデータが大きかったりする場合は多少変わってくるかもしれません。

今回はちょっとした小技の紹介でした。
（ちなみに export-ignore を確認したときに知ったのですが、export-subst でなんか面白い使い方できないかなぁと思った）

ではでは。

【GitHub Actions】actions/labeler 互換で on.pull_request 以外でも使えるアクション srz-zumix/labeler-action を作りました

actions/labeler 便利ですよね。
でもちょっと困ったことがありました。
過去の PR に対してルール適用をしようと思ったところ、ブランチ名ルールが pull_request イベント前提のコードになっていて、workflow_dispatch で PR 番号指定して実行したときに設定どおりにラベル付けできませんでした。

この問題の修正 PR を出してはいるんですが反応がないので、自分で作りました。

srz-zumix/labeler-action

使い方は actions/labeler とほぼ同じです。

labeler の設定ファイルと同じ設定ファイルが使えます。
labeler-action は `dot: false` には対応していないのですが、ラベルの色設定に対応しています。labeler はラベルがない場合にラベルを作成してくれはしますが、色がグレーになってしまうのでちょっと不便でした。

色指定は以下のようにします。

ci:
- any:
  - changed-files:
    - any-glob-to-any-file: '.github/*'
- color: '#7c0bb2'

aqua:
- changed-files:
  - any-glob-to-any-file: 'aqua.*.yaml'
- color: '#1E90FF'

documentation:
- changed-files:
  - any-glob-to-any-file:
    - 'docs/*'
    - README.md

都合が良いことに color の設定があっても actions/labeler では無視されてエラーにはなりません。

ちなみに labeler-action はツールを呼び出しているだけで処理の実体は srz-zumix/gh-label-kit にあります。こちらも私が作っているもので、GitHub のラベル関係の操作を行える gh-extension となっています。
この拡張機能の１機能として labeler コマンドを実装しています。
したがって、gh-label-kit を使っていただければ GitHub Actions を使わず、ローカル環境からでもラベル設定が可能になります。
その他にも gh 標準には（今のところまだ）ない機能が揃っているので是非使ってみてください。

また、今回は gh-extension を gh extension install するのではなく、aqua を使用してインストールしています。これは self-hosted runner のことをちょっと意識しています。
aqua はまだ使い始めて間もないので、もっと便利な使い方を実践していきたいです。


以上です。ではでは

【GitHub Actions】任意のスクリプトを Post 実行するアクションを作った

srz-zumix/post-run-action

リポジトリはこちちです。
機能としては run step と同等のことが Post タイミングで実行できるアクションです。

アクションには後片付けをするタイミングとして Post 処理が書けます。
よく使う actions/checkout も Post 処理で git config などを元に戻す処理がされています。
実行ログを見ていただくと、下図のように Post 処理が並んでいると思います。



このようにワークフローで手軽に Post 処理を記述ができようになる便利なアクションが post-run-action です。
もちろん post-run-action を使わずとも if: always() なステップを最後に追加すれば、後片付けをすることは可能です。

後片付けしたい処理と、後片付け処理を近くに書いておけるのがメリットでしょうか。
例えば、長いワークフローだと Post step が遠くて分かりづらいかもしれません。

      steps:
      - name: Checkout
        id: checkout
        uses: actions/checkout@v4
      - name: Do
        run: |
          echo "TODO"
      - name: Post Action
        uses: srz-zumix/post-run-action@v2
        with:
          post-run: |
            echo "Post run step"

      # ...

      - name: Post
        if: always()
        run: |
          echo "Post run step"

そのような場合には、アクション化してしまうことも1つ手段かと思います。
しかし、残念なことに現状 composite action で Post 処理が書けません！
JavaScript action なら Post 処理を書けますが、複数のステップをまとめてアクション化する場合、composite が書きやすくそれを選択しがちです。

そこで post-run-action を使います！
実は composite で Post 処理が書けないことをなんとかしたくて作ったのがこのアクションなのです。

post-run-action を使うことで好きなタイミングで後片付け処理をセットできるようになります。私が作成したアクションの中でも業務でよく使っているアクションの1つになります。
ぜひ使ってみてください。

では。

GitHub Search と NotebookLM で自分の活動を振り返る

GitHub Search で昨日何してたっけ？を簡単に

gh-activity-report という gh 拡張機能をちょうど2年前くらいに作っていました。
こちらは GitHub の検索APIを gh search コマンドをつかって簡単に呼び出し、結果をレポートとして使いやすいように加工して出力する gh 拡張機能です。
gh search 使えばできることなので、わざわざ拡張機能を作る必要もないのですが期間の指定を「XX日前以降」とか「今月」とかがめんどくさかったのでこれを作りました。

例えば、昨日以降に更新した PR および Issue を検索する場合はこのようになります。

gh activity-report -d 1

これを gh search で書くとこのようになります。

gh search issues --include-prs --sort updated --author @me --updated ">=2025-04-21"

今日の日付に合わせて、コマンドを実行する必要があるのでちょっと面倒くさいですよね。
自分は下記コマンドで gh ar -d 1 で呼び出せるようにエイリアス設定をしています。
昨日何してたっけ？先週何してたっけ？と良くなるのでとても便利です。

gh alias set ar activity-report

GitHub Search の結果を定時報告に使う

さて、この gh-activity-report ですが gh search の出力フォーマット以外にも対応しています。gh コマンドをよく使っている人は --jq や --template オプションで出力加工ができることをご存知かと思います。 gh ar でやる場合は -- を使います。

gh ar -d 1 -- --json url --jq ".[].url"

単純な加工であればこれで十分ですが、ちょっと凝った出力にするのはやや面倒です。
--format オプションでいくつかパターンを用意してます。下記は一例です。

gh ar -d 1 --format markdown

gh ar -d 1 --format list

自分用に用意したものなので、お好きなフォーマットにする場合は前述のオプションか、json format で出力して結果をテンプレートエンジンなどで加工するとかもできると思います。
（私は kamidana を使った自作の kamidana-action をよく使っています）
gh の --json オプションは欲しいキーを指定しないといけなく、全部が面倒くさいのですが --format json なら簡単に全部出力できます。

gh ar -d --format json

私はこれらを組み合わせて、週報を自動で書かせています。

定期的なふりかえり

もともとこの拡張機能は活動の報告やふりかえりを目的として作成しましたが、これらは評価のためでもありました。

年に1回や半年に1回のタイミングだとどうしても記憶が曖昧になっていたり、直近の記憶が強くなりがちです。何やってたんだっけ？と毎回なります。
拡張機能で半年間の活動を出力させることもできますが、量がすごく多いのでそれで振り返るのもまた大変です。なので、月ごとにふりかえりをして記録をするという手段を取っています。これを自分リリースノートという名前でやっています。

（個人活動の方でも昔やってましたが、今は止まってます・・・）

自分リリースノートは自身の成長を観点としています。記録にはその観点フィルターを通した要約結果が記載されています。
今回、たまたま別の観点でふりかえりをしたいというきっかけがあり、もう一度 PR などの活動を見返す必要があったので、 NotebookLM に手伝ってもらいました。

NotebookLM で自分の活動をふりかえる

NotebookLM のソースとして gh-activity-report の出力を与えてみましたが、既存のフォーマットでは微妙だったので今回それを目的としたフォーマット（lens-with-body）を追加しています。私がブログを休んでいた期間の情報を出力すると以下のようなオプションになります。

gh ar --since 2023-04-01 -l 1000 --format lens-with-body --visibility public

どのようなフォーマットかというと「repository,number,url,state,title,createdAt,closedAt,updatedAt,author,body

」キーの情報を平文でただただ出力しているだけです。（長いので結果は省略）
既存のフォーマットは GitHub にそのまま書きやすい、人が読みやすいものが多かったのですが、今回のフォーマットは情報をダンプしている感じで人が読みやすいとは言い難いです。

出力した結果をソースとしていれて、どのような活動があったかまとめてもらいました。

なんかいい感じです。
AI の登場で情報をまとめて要約することが手軽になりましたね。

最初は全期間の１ソースだけ用意していたのですが、いまいち認識が甘かったので期間を分割して複数のソースとしました。単純にファイルサイズ（トークン数）というわけでもなさそうで、自分の PR の body がほとんど空っぽだったせいもあるような気もしています。
また、期間中の PR が月ごとに何件あったか調べてもらったら、微妙に一致しなかったりしました。

ちなみに、クセで目的とは関係なく挙動の実験をしてたら、このブログを書くのが２ヶ月遅れましたw　いろいろ調べてみるのは楽しいのですが、現時点での AI に合わせてもしょうもないのでキリにします。

AI 関連の変化は目まぐるしいので、上手に向き合っていけたらいいなと思ってますね。

私は AI 自体に詳しいわけでもなく、利用者としても初心者レベルなので、どちらも触れていって、自分の引き出しを増やせればと思います。

Gemini ではどうか？

Gemini でも同じことができます。
NotebookLM は json ファイルに対応しておらず、平文化する必要がありましたが Gemini だとそのまま json をソースにできるので楽でした。
目的にあわせて使いやすものを使うのが良いんじゃないかなと思います。

最後に

久しぶりブログ書いたけど、感想文みたいになっちゃいましたね。
最近は gh 拡張とか GitHub Actions のアクションを作ってることが多いので、そのへんも紹介できたらいいなと思ってます。では。

おひさ！

どうも久しぶりです。いつぶりの投稿でしょうか。約2年ぶりみたいですね。。
ここ数年は仕事が楽しくて社内での活動ばかりでした。
…というのも言い訳でして、一度途絶えた習慣を元に戻すのは大変だなと感じてます。
リモートワークになり通勤がなくなったのが一番の影響でしょうか。
出勤途中のスタバで記事を書くというのが習慣だったんですよね。
私物 PC を毎日リュックに入れて通勤してました。たまに会社の PC も持ち帰ることがあったので2台背負って電車に揺られる日もありました。信じられません。

最近は公式ドキュメント読めば OK だったり、 Zenn や Qiita などの記事を見ることや、
AI に聞くことが増え、個人ブログで情報を得る機会がかなり減ってしまいました。
（消しゴムの跡）
このへんはいろいろと思うところもあるんですよね。自分がこのブログを書く意味ってなんだろう、とか。

（テキトーなこと言ってます）

あと、これまでインターネット上の自分は本名の自分と別として活動してました。
まぁ隠してたわけではないですし、それなりの人に = あの人と認知されていることは知ってはいましたが、ここ数年でこの = 認知の範囲が広がったんじゃないかなと思ってます。
今までのように仕事成分抜いて投稿するってのもやりづらいなぁと勝手に感じております。

と、ネガティブな理由を書きましたが、それを書くために再び筆を執ったわけではないです。
最近、若手の活躍や意欲の高さにあてられて、自分も何かやりたくなったからですね
この2年間なにもしてなかったわけではなく、OSS活動はずっとやってきてましたし、公にやったことの話なら問題ないので、また書くことにしました。

書くペースはどうでしょうね？以前のように週一回更新はできないかもしれないですが、2年分の貯金でしばらく頑張ってみましょうかね。こういう形での不定期連載もありだろうか？
まぁまだしばらくこのブログで個人活動を続けようかと思います。今後ともよろしくお願いします。

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 コンテキストに限らず使えます。


今回は以上です。

GitHub Actions で停止してしまったスケジュールワークフローをリストアップする

メインブランチに更新がない状態が続くとスケジュールで動くワークフローは無効化されます。
無効化される前に通知が来てリンクからワークフローのページを開いて「Enable workflow」を押す必要があるのですが、わりと忘れがちでいつの間にかワークフローが止まっていることがありました。
そして無効になってしまったあとは特に通知も来ないので、たまたま見に行ったときに気づくことがほとんど。
無効になってしまったワークフローを一覧できたらなーと思っていたのですが、gh でできそうだったのでやってみました。

一覧

gh repo list --json nameWithOwner --jq .[].nameWithOwner | xargs -I {} sh -c "echo {}; gh workflow list -a -R {} | grep disabled"

無効になっているワークフローは disabled_inactivity ステータスになっているのでリポジトリリストからワークフローリストを取得して grep しています。

Web で開く

gh repo list --json nameWithOwner --jq .[].nameWithOwner | xargs -I {} sh -c "echo {}; gh workflow list -a -R {} | grep disabled | grep -oe [0-9]*$ | xargs -I WID gh workflow view -R {} WID --web"

「名前 ステータス ワークフローID」が出力されるので末尾の ワークフローID を取得してブラウザで開くコマンドを呼び出します。

無効になっているワークフローのページが開くのでそこで「Enable workflow」ボタンを押せば有効に戻せます。

Enable にする

gh repo list --json nameWithOwner --jq .[].nameWithOwner | xargs -I {} sh -c "echo {}; gh workflow list -a -R {} | grep disabled | grep -oe [0-9]*$ | xargs -I WID gh workflow enable -R {} WID"

gh workflow enable でワークフローをコマンドラインから有効にすることもできるので、Web で開く部分を少し変えればワンライナーで全リポジトリのワークフローを有効に戻せます。

今回は以上です。では。

Ansible で実行中の bash script を上書きしても大丈夫なのか試してみた

表題どおりです。
1年くらい前の話題ですが、アドベントカレンダーに空きがあれば投稿しようと思って書いてました。
自分の dotfiles のインストールを ansible に少し移していこうとしてる repo で試しました。

結論は ansible のモジュールを使っていれば大丈夫です。
（モジュール内で適切に処理されてない可能性はありえるが、それはほぼないと思っていいのではないかと思います）

詳細は repo を参照してください。
https://github.com/srz-zumix/ansible_dotfiles/tree/main/roles/bash-cp-test

GitHub Actions の Composite Action で post 処理を実現する方法の訂正

GitHub Actions の Composite Action で post 処理を実現する方法

こちらの記事で「./」でパス指定すれば OK って書いたのですが、これは自分自身をチェックアウトしてたのでできたことでした。
このアクションを使う場合はアクションの実体は GITHUB_ACTION_PATH 環境変数の指す場所にあり、uses をパス指定する場合は workspace からの相対パスになるのでこの方法ではダメというわけです。

uses で env は使えないので（静的に解決される必要があるかな？使えれば env. GITHUB_ACTION_PATH で良かったのですが）、workspace の .github/ 配下に post-action のシンボリックリンクを貼って、そのパスを指定するようにしました。

https://github.com/srz-zumix/setup-service-jenkins/pull/27

ちょっと微妙な感じもしますが、他に回避方法思いつかなかったのでこうしました。
composite action でも早く post 処理できるようになるといいなー。
（post action 用の repo or branch 用意するのも考えたけど、コードが分離するのが嫌だったのでやめました。でも、指定したパスの shell script を post 処理で実行するだけの action はあってもいいかなーと思いました。）

以上。