ブログズミ

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

2026-10-15T09:20:01.102+09:00

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 の章を書きました

2026-09-28T09:36:01.948+09:00

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

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

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

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

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

Microsoft MVP 初受賞しました

2026-09-08T10:31:55.558+09:00

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

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

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

2026-08-31T11:10:17.078+09:00

みなさん、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 を切り替える方法

2026-06-09T09:39:43.167+09:00

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 を更新しました

2026-01-17T19:23:00.001+09:00

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-12-31T23:56:00.006+09:00

さて、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月初旬の活動は、その見事な証拠を示しています。

12月02日: まず基盤となるgo-gh-extensionに「Guardrails」という機能が追加されます（PR #67）。
12月03日: 翌日、その機能を活用する形でgh-team-kitに「Guardrail」が実装されます（PR #85）。
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日の活動を見てみましょう。

16:04: gh-label-kitリポジトリで、バージョンを0.12.0から0.12.1に上げるプルリクエスト（#76）がマージされます。
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つの習慣を抽出しました。これらは独立した習慣ではなく、相互に連携する一つのシステムとして機能しています。

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

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

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

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

2025年も残りわずか！

2025-12-31T20:38:00.001+09:00

みなさん。こんばんは。
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 でアクションのサイズを小さくする小技

2025-09-10T10:58:00.001+09:00

こんにちは。皆さん 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 を作りました

2025-09-01T10:25:00.001+09:00

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 実行するアクションを作った

2025-07-10T09:32:00.001+09:00

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 で自分の活動を振り返る

2025-06-23T09:28:00.001+09:00

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 のアクションを作ってることが多いので、そのへんも紹介できたらいいなと思ってます。では。

おひさ！

2025-06-23T09:27:00.001+09:00

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

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

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

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

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

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

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

2023-06-28T10:14:00.001+09:00

はじめに、雑な説明

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 配下にあるすべてのリポジトリをマトリックスにする

2023-05-28T18:35:00.001+09:00

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 を仕込む

2023-04-19T22:43:00.001+09:00

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 で停止してしまったスケジュールワークフローをリストアップする

2023-02-22T10:05:00.001+09:00

メインブランチに更新がない状態が続くとスケジュールで動くワークフローは無効化されます。
無効化される前に通知が来てリンクからワークフローのページを開いて「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 を上書きしても大丈夫なのか試してみた

2023-01-18T10:03:00.001+09:00

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

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

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

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

2022-12-27T10:19:00.001+09:00

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 はあってもいいかなーと思いました。）

以上。

Git に Contribute してみた

2022-12-15T00:22:00.002+09:00

この記事は「Gitのカレンダー | Advent Calendar 2022 - Qiita」の 15日目の記事です。

Git そのものの修正を出したい、手順ってどうすればいいんだろ？
と検索しても GitHub で OSS に貢献（Contribute）する方法みたいなのがヒットして役に立たず。
結局、公式の英語文とにらめっこして Contribute したので備忘録です。

はじめに

出した PR はこちら
https://github.com/gitgitgadget/git/pull/1406

そしてこの修正が含まれた Git 2.39 がリリースされました。

Highlights from Git 2.39 | The GitHub Blog
[ANNOUNCE] Git v2.39.0 - Junio C Hamano

Changes にアカウント名が載ってましたねぇ。嬉しい。

Contribute 方法

さて、まずはじめに Git はよくある OSS のように GitHub での Pull Request を出したらレビューされて Approve されたらマージされる。というフローではありません。
基本的にメーリングリストにパッチを送る形式のようです。

CONTRIBUTING.md

ただ、メーリングリストは自分もそう感じましたが非常にハードルが高いです。（英語だし）
そこで私は GitGitGadget に PR を出す方法で Contribute してみました。
やり方はドキュメントをたどっていけばわかりますが、日本語情報がなかったので、かなり慎重になりました。

ドキュメントはこちら MyFirstContribution

修正をする

修正するまでは他 OSS の場合とあまり変わらないですが、まず gitgitgadget/git に PR 出すのでこちらから fork しましょう。
修正したらビルドして動作確認、テストをすることになります。
この辺は README 読めばわかると思うので省略。
ちなみに今回の PR は1行修正であることと、テストってどうやる？どうやってる？って感じの内容だったのでやってません。
（実際にはやったけど自分の環境では修正と関係ないところがパスしなかった。PR 出すとテストされるのでそっちに任せました。ごめんなさい）

コミットをする

変更できたら、次は commit します。
ここは少し注意が必要です。コミットメッセージは当然英語ですが、そこは頑張ってください。

1つ目は git commit に --signoff (-s) をつける必要がある点です。このオプションを付けるとメッセージに「Signed-off-by: <user.email>」のメッセージが追加されます。
これが必須なので普段つけてない人は気をつけましょう。

2つ目は commit メッセージのフォーマットが決まっている点です。
.editorconfig で1行あたりの文字数が設定されているので、.editorconfig 対応してるエディタでコミットメッセージを編集するのをおすすめします。
コミットメッセージの1行目は変更対象のコンポーネント名を含む 50 文字以下で概要を書きます。
1行空行を空けたあとに、変更の詳細を書きます。
詳細には、コード差分からは読み取れない部分を書くことが重要です。

自分の場合、今回はとにかくメッセージの部分に時間を取られましたが、過去の commit のメッセージを参考にしてシンプルな日本語文章を書いてから、少しずつ翻訳ツールを使って英語のメッセージにしました。
（普段英語できないのにテキトーな英語使ってたが、今回はかなり気を使った。。）

プルリクエストを出す

commit したらプルリクエスト（PR）を出します。
PR を出す先は gitgitgadget/git なので気をつけてください。
やり方はこちらに記載されています。
https://git-scm.com/docs/MyFirstContribution#send-pr-ggg

PR の内容はメーリングリストに流れるカバーレターのタイトルと本文になるので、こちらもドキュメントを参考に書きましょう。

カバーレターについてはこちらに記載されているので、これを参考に PR のタイトルと本文を記載します。
https://git-scm.com/docs/MyFirstContribution#cover-letter

今回のように修正が 1 commit であれば、commit の概要をタイトルにしても良いと思います。
説明文のほうは、commit や commit メッセージでは読み取れない補足情報を書きます。
今回は簡単な内容説明と再現条件を記載しました。

これも過去の PR を参考にすると良いかもしれません。

PR 後の対応

PR を作成すると bot からのメッセージが投稿されます。
こちらにも Contribute 方法について書かれてます。
それに記載されてますが、初めて Contribute する場合は許可された GitHub ユーザー名にないため、すでに許可されたユーザーから /allow のコメントをもらう必要があります。

自分の場合は幸運なことに特になにもせずとも /allow されました。
もし /allow されない場合は issues から /allow コメントを出してる人を探すといいそうです。

（すでに /allow されたユーザーなら誰でも /allow できるっぽいので今度は自分が /allow できるってことか。つまり私に /allow してーと頼むことも可能ってことか。）

次に /submit コメントを書くと、PR の内容がメーリングリストに投稿されます。
が、その前に /preview で投稿されるメールを確認できるので、しておきましょう。
GitHub に登録してるメールにプレビューメールが届きます。
内容に問題がなければ /submit コメントを送ります。

メーリングリストの返信や patch のステータスなどがボットにより自動で PR に送られてきます。
メーリングリストで修正依頼や質問などが来たら返信する必要がありますが、今回は特に眺めてるだけで取り込まれました。（軽微な修正でしたので）
ドキュメントにそのようなケースの対応方法も書いてあったので、たぶんそれを見ながら対応すれば大丈夫だと思います。（経験しなかったので省略）

あとは勝手に進んだのであまり知見として得るものはなかったのですが、待っていたら master に取り込まれて PR は close になります。
（PR は merge されず close になります。取り込まれたかどうかは label でわかりそうです）

最後に

最後の方は待ってるだけで、これなにもしなくていいのかな？認識間違ってるかな？と不安にもなったのですが、結果的に取り込まれてそれがリリースされたのでとっても嬉しいです。
なんか、Git そのものに Contribute するというのはちょっと特別感がある気がします。

Git 自体の修正って大変そう。難しそうというイメージがありましたが、今回の PR 内容は調べてみたらそんなに難しい修正じゃなかったです。みなさんも普段 Git を使っていてなんか変だな？バグかな？と思ったら Contribute にチャレンジしてみてはいかがでしょうか？

とりあえずあまり有益な記事じゃないかもしれませんが、怖くないよってことが伝われば幸いです。ではでは。

【Make formerly Integromat】Twitter でいいねした画像を自動でクラウドストレージに保存する

2022-11-24T22:10:00.001+09:00

最近、お絵かきをしたいなと思ってちょこちょこ描いてるのですが、今は昔よりも簡単に上達するための手法や、Twitter の投稿でお手本を見られるので、思っていたよりうまくなった気がしてます（自己満）
まぁまだまだ下手くそなんですけどね。それでも昔のなんかうまく描けないって感じの絵からは脱却できたと思う。

はい。ここまでがまっとうな言い訳なんですが、Twitter でこのひとの絵上手だな、この構図いいな、こんな塗り方もあるのね、といいねした画像がいっぱいあるのですが、参考にしたいなというときにいいねを遡るのは大変なので保存することにしました。
（決して助平心の極みではありません）

では早速シナリオへ

シナリオは 4 つのモジュールだけなので簡単な方です。
まずはじめにトリガーになる Twitter モジュールです。
※Twitter モジュールを使用するので有料プランが必要です。

トリガーは毎時設定で、「List Likes」モジュールで最大5件取得するようにしています。

When to start を過去からにしたら昔のいいねを順次5件ずつ処理されます。
（全件は取得できないです。ページング対応してないからと思われます）

次の Iterator ですが、これは１ツイートに複数の画像がついている場合があるので「Extended entities: Media[]」配列をループさせてます。

次の HTTP モジュールで取得した画像 URL からファイルをダウンロード

最後にダウンロードしたファイルを Dropbox モジュールでアップロードしてます。

アップロード先は好みで変えてください。

（サービスのモジュールがない場合は HTTP モジュールで頑張るか、FTP や SFTP モジュールになると思います）
ファイル名は複数枚画像があった場合に同じファイル名にならないように Iterator からインデックスを取って名前に含めるようにしています。
今回は単純にツイートIDをファイル名に含めるだけにしていますが、Twitter モジュールからツイートの情報が取れるので必要に応じて情報を残すと良いと思います。

実際に運用している Dropbox はこんな感じです。

いいねしておいたら勝手に保存されるので、どんどんいいねしちゃいますね！

ではでは。

git で新規ブランチ作成時の typo を防ぐ

2022-11-10T09:28:00.001+09:00

あまり実用的ではないものの参考までに紹介します。
（というのも最近趣味プログラミングしてなくてネタがない・・）

git でブランチ作成するときに feature って名前をつけることがよくあると思いますが、
これを typo して faeture だったり featrue だったりで push してしまうことがあります。

ただの名前だしまあそんなに気にしなくても。。と思いますが、
ブランチ切替時の入力補完が f や feat とかで止まってしまって1手順増えてしまいます。

たかが1手順とはいえ、体験すると割とストレスだし、開発メンバー全員に影響があることなので実は思っている以上に生産性を下げてしまっている。かもしれません。
（体感です。計測してるわけじゃないです。）

トイルといえるかもしれませんね。
スケールもすると思うので、改善のコスパは良い気がします。

。。少し脱線しましたが、本題へ

commit メッセージの typo チェックはよくあるけど、ブランチ名の typo チェックはあまり聞きません。
ブランチ作成時の hook はなさそうだったので、多くの人が作ってるであろうブランチ作成の alias に手を加える方法にしました。

typo 修正付きブランチ作成 alias

できた alias はこちらです。

[alias]
  cob = "!f(){ echo $1 | sed 's|/| |g' | typos - -w | sed 's| |/|g' | xargs -I% git switch -c %;};f"

こうなります。

typo チェックツール

今回使った typo チェックツールは typos です。
他に misspell も使ってみたのですが、feature の typo のいずれのパターンも修正できなかったので typos にしました。

typos は feature_test は分解してチェックしてくれますが、feature/test は分解されなかったので、sed で一度スラッシュを空白に変換してます。
空白にしたのは typos のあとでもとに戻すときに、都合が良いからです。
（_ だともともと _ だったものも / にしてしまう）

ちなみに typos でも faeture は feature になおしてくれますが、featrue はダメでした。
辞書とかあれば改善するかもしれませんが、今回はネタレベルで書いた alias なのでパスします。

最後に

こういったちょっとした手間でもスケールすれば効果は大きくなります。
最近は自称 SRE として改善を生業としてますが、こういったお遊びも役に立つことがあるでしょう。

以上。

【GitHub Actions】コンテキストダンプのススメ

2022-10-18T10:35:00.000+09:00

GitHub Actions では github や job などのコンテキストから git の状態や PR の内容、ジョブの情報などが取得できます。
これらを利用してステップの条件をつけたり、処理を変えたりなどができます。
さて、このコンテキストですがどういったものがあるのかは、ドキュメントで確認できます。

コンテキスト - GitHub Docs

ただ、実際にどういった値が入っているかまではわからないですし、ランナーやジョブによって当然値は変化します。
なので、コンテキストをダンプするための repository を用意しておくととても便利です。
私は ci-spec repository でいろいろなイベントトリガーでダンプできるようにしてあります。
https://github.com/srz-zumix/ci-specs/blob/master/.github/workflows/events.yml
この情報って取れるのかな？って探すことが結構あるので重宝してます。

また、github context の json は nektos/act の入力イベントとしても使えるので、常にダンプしておくと便利かもしれません。。かも。。

今回は以上。
act のことは「ブログズミ: nektos/act で GitHub Actions のワークフローをローカル実行」と「GitHub Actions のローカル実行ツール（nektos/act）を便利にする gh extension を作った」で書いたのでよければ見て下さい。

Homebrew と git fsmonitor の相性が悪かったので対策した

2022-09-21T09:13:00.000+09:00

「Git 2.37.0 で FSMonitor daemon が追加されたことで status が早くなったそうです」
この記事で fsmonitor の事書いてしばらく使っていたのですが、brew upgrade したときにたまに以下のエラーで失敗するようになってしまいました。

Error: Another active Homebrew update process is already in progress.
Please wait for it to finish or terminate it to continue.

これは Homebrew 3.5.7 で対応されたので、現在は発生しなくなっていると思います。

当時はあんまり調べる時間なかったので、一旦 fsmonitor を無効にしてましたが、修正 PR と Issue をみた感じ fsmonitor が homebrew の lock ファイルを掴んでしまうからみたいです。

Homebrew 3.5.7 は fsmonitor を stop させる対応となっていますが、そもそも監視しておくメリットってあるのかな？ということで、 brew 配下だけ fsmonitor を無効にする設定を紹介します。

ちなみに brew に追加する tap も git なのでそれらも無効にします。

includeIf を使って任意のディレクトリ以下の git config をカスタムする

グローバル設定は false で使いたいディレクトリだけ true にするとか、brew 配下のワーキングディレクトリすべてに git config core.fsmonitor false していけばいい話ではあるのですが、デフォルト true で使いたい＆一括 false 設定をしたいです。

そこで、includeIf を使います。

includeIf はその名の通り、条件を満たした場合のみ config を include する機能です。
リンク先のドキュメントに Example があるのでどういうことができるのか想像できると思います。

今回は brew --prefix のパス以下の場合に fsmonitor = false にした config ファイルを読み込ませます。
（brew --prefix に合わせて適宜変更してください）

これだけです。簡単ですね。
includeIf 使うと特定のディレクトリ以下で user 切り替えるとかもできるので覚えておくと良いテクニックだったと思います。

おまけ

https://github.com/jgavris/rs-git-fsmonitor

これはたまたま見つけたデフォルトの fsmonitor の hook スクリプトを Rust rewrite したやつ。
fsmonitor って true/false ではなくて hook スクリプトを指定することもできるんですね。

git status がもっと速くなるみたいですよ。
（筆者環境では差は感じられなかった）

Dagger 使ってみた

2022-09-13T10:59:00.003+09:00

Dagger とは？

Dagger は CI/CD パイプライン用のポータブルな開発キットです。

Dagger は他の一般的な CI/CD が YAML でパイプラインを記述するのと異なり、CUE で記述します。CUE については後述しますが、YAML よりプログラミング言語に近くて柔軟性が高いって感じですかね。

CUE によって YAML ではやりづらかったパイプライン再利用が容易になっています。

また、Dagger はローカルでも CI でも、どこでもパイプラインが実行できるのが特徴です。

Dagger はすべてコンテナ上で実行されます。コンテナが動く環境上であればどこでも「同じ」パイプラインを実行できるのが Dagger であり、CI/CD ツールではなく、パイプラインを共通化するレイヤーとして機能するツールです。

CUE

https://github.com/cue-lang/cue

CUE は Configure, Unify, Execute の頭文字のようです。
CUE は JSON のスーパーセットで、CUE から JSON/YAML にエクスポートも可能です。

CUE については Dagger のページにも説明が詳しくあるのでそちらを参照してください。

https://docs.dagger.io/1215/what-is-cue/

CUE は YAML のマージ機能も備えているので↓みたいな使い方もできるみたいです。これはこれで便利そうですね。

「CircleCI の設定ファイルを分割して CUE で合成してみたら割と簡単で便利そう - Mitsuyuki.Shiiba」

今回は Dagger の話なので CUE そのものもそのうち触ってみたいです。

使ってみる

ものは試しで、使ってみました。
Dagger のサンプルとして todoapp があるのでそれでまずは動作を試してみるのがオススメです。このへんはありきたりな内容になってしまうので、省略します。

iutest に適用

iutest は筆者が書いてる C++ テスティングフレームワークです。
（まぁ最近はテスティングフレームワークの機能開発はほとんどしてないんですが・・いろんな CI サービスを使っている・使っていたのでそういう意味では参考になることもあるかもしれないです。）

今回 alpine イメージ上でのテストを今までしてなかったので、それを Dagger でやるようにしました。

ベースとなる cue ファイルはサンプルの todoapp を使いました。

1から書くよりもサンプルなどをベースに書いていくと楽だと思います。

なんですが、todoapp が参考にしたときと大分違う設定になっていました。
ちょうどそのころの Dagger 使った系の記事があったのでそちらを参考にしてください。
「ベンダーロックインしないCI/CDパイプライン、Daggerを使ってCodeCheckを自動化してみた。」

「コンテナベースのCI/CDツール「Dagger」を試してみよう - Qiita」

どういうふうに書いたかは百聞は一見に如かずということで、レポジトリを見てください。
この記事向けにコメントも追加してます。

https://github.com/srz-zumix/iutest/blob/develop/iutest.cue

とはいえ、見てくださいだけではこの記事の意味がないのでこの設定に至るまでの紆余曲折を記述しておきます。

変数展開は () でする

同じ設定はまとめたいので変数にしてたのですが、使うときに単純に変数を書くだけじゃだめでハマりました。

       // 必要な環境変数をセット
        env: {
            // string は () で囲んで展開する
            IUTEST_ROOT_DIR: (iutest_root_dir)
            // 文字列の中で変数展開する場合は ( をエスケープする
            IUTEST_OUTPUT_DIR: "\(test_result_dir)"
        }

exit: 0 は今の所意味がない

CTest が失敗しても後続の処理を継続したかったので終了コードを 0 に上書きしたいなーと思ったのですが、今はできないっぽい。
なので、しかたがないので script: contents の処理で失敗を無視してます。

always は condition の always ではない

↑と同じ理由で常に実行される処理を書きたかったので、always を使ってみたのですが、どうやらこれは実行条件の always とはちょっと違って、cache 利用するかしないかの always だったようです。
always を true にするとキャッシュを無視して常に実行されるようになりますが、依存処理が失敗していても実行するようなことはできませんでした。

https://docs.dagger.io/1231/always-execute/

常に実行したいってのは cache invalidate のことではないんだよなぁ・・

GitHub Actions で動かすには

dagger の cue ファイルを置いておいても、そのままでは CI サービスで実行されないので、各サービスでワークフローを書く必要があります。

GitHub Actions の場合は、dagger 用の action があるのでそれを使えばすぐに動かせます。

  dagger:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: dagger/dagger-for-github@v3
        with:
          cmds: |
            project init
            project update
            do ctest

CUE/Dagger を新たに覚えるのはつらい

ここから使ってみた感想なのですが、CUE が使いやすいかというとまだわからないのですが、少なくとも覚えることは多い印象。
YAML でのパイプライン記述における問題の１つである再利用性を CUE は解決していますが、最初に紹介した CUE を YAML のマージツールとして利用することで十分なような気もしますし、各 CI ツールで再利用性できる機能があったりしますし、Dagger である必要性があまり感じられませんでした。

より理解をするには CUE と Dagger の境界を認識して、それぞれで調べる力、検索力が必要になるかなと思いました。

ポータビリティについて

環境のポータビリティ

Dagger は「環境」のポータビリティを実現しています。

CI でもローカルでも同じ「環境」で処理を実行できます。

ローカルと CI で同じ「処理」をすることは Makefile でもなんでもいいですが、可能です。

なので CI と同じ「処理」をすることは Dagger を使わなくても可能です。
ただ、それだと実行環境は CI やローカルで異なるため、実行結果は変わってきます。
Dagger は実行環境もセットになっているので、同じ「環境」で同じ「処理」ができ、CI とローカルで同じ実行結果が期待できます。

これは大きなメリットです。仕事や個人開発でも CI でしか起きない問題の調査はめんどうです。ローカルで同じことができればこれも楽になります。
また、問題調査としてではなく開発者がローカルで動作確認をしたい場合に、ローカルで手軽に実行できるのも利点ですね。
私はゲーム開発に携わっているので、ターゲットプラットフォームでのビルドをローカルでしたいという需要はすごくわかります。（Dagger でゲーム開発のターゲットプラットフォームビルドができるかというと難しい気がしますが・・）

ただ、Dagger の実行環境はコンテナに制限されるため、コンテナでできないことはできません。
また、iutest はテスティングフレームワークなので、１つの同じ環境でテストするよりも、多様な環境でテストできたほうが嬉しいです。（※Dagger で複数環境用意するのもありですが、管理下の想定された環境よりも、管理外の環境のほうが意味があると思っている）

今回は alpine コンテナでのテストが今までなかったので Dagger を採用して GitHub Actions で動かしています（Dagger も環境の１つなので何かしらのテストを回しておきたいという意思）。

ワークフローのポータビリティ

ワークフロー？パイプライン？
言葉の定義があいまいなんですが、ここでは PR トリガーから結果の通知など CI の最初から最後までという意味合いでワークフローを使ってます。

「A PORTABLE DEVKIT FOR CI/CD PIPELINES」

Dagger のトップページにはこう書かれています。
パイプラインという言葉を使ってるので Dagger がカバーしている範囲はパイプラインと呼びます。

図にするとこんな感じかな。

Jenkins でジョブに直接処理を書かずに .sh ファイルとかにしようね。とか。ビルドツール使おうねとか。そららはパイプラインの話。

それのもう１つ上のレイヤーで環境とセットでまとめてくれるのが Dagger 。

さらに上のレイヤーであるワークフローはそれぞれ対応する必要がある。

Dagger はベンダー依存しない CI ツールという立ち位置ですが GitHub Actions での実行例を見ていただければ分かる通り、特定の CI サービス上で Dagger を実行するには Dagger だけでは完結しません。というか、GitHub Actions でいうとトリガー部分（on: pull_request）は Dagger では設定できませんし、動かす CI サービス固有の機能を使いたい場合は Dagger 外でやる必要があります。（Dagger はそういう CI の差を埋めてくれるものではないので）

そして CI サービスを引っ越しする場合には、トリガー周りなどそういった設定は書き直しになります。

CI/CD ワークフローのポータビリティという観点では、Dagger は直接的に貢献するわけではないです。（パイプライン部分だけでもポータブルになるので楽にはなる）

ただ、どのサービスを使うのか決まっているのであれば、そのサービスの書き方をしたほうが良いとも思えます。

逆に社内で使ってる CI サービスが多種多様であるとか、OSS だから手軽に乗り換えできると嬉しいとかであれば、Dagger を使う利点はあると思います。

ローカル実行について

実はローカル実行できる CI サービスもあります。
なので目的や事情によってはそのサービスのローカル実行機能を利用したほうがいい場合もあるかもしれません。

例えば CircleCI では cli からローカル実行できます。（制約はあります）

GitHub Actions の場合、nektos/act というツールを使えばエミュレートできます。（act は大分できないことや、Hosted runner との差異がありますが・・）

これらで十分なのであれば Dagger に置き換える必要はないと思います。
例えば、act は GitHub Actions のイベントをエミュレートしてくれるのでワークフローのローカル実行が可能ですが、Dagger は step レベルのローカル実行しかできないです。
このへんは使い分けでしょうね。

act のことは「ブログズミ: nektos/act で GitHub Actions のワークフローをローカル実行」と「GitHub Actions のローカル実行ツール（nektos/act）を便利にする gh extension を作った」で書いたのでよければ見て下さい。

まとめ

個人的には最近使ってみた Earthly の方が Dagger より使いやすいなと思いました。
Dagger がちょっと話題になりましたが、類似のツールと比較したり、今置かれている状況を踏まえて選択するのが良いと思いました。

以上、久しぶりに長めに書いた。ではでは。