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++ を使っていたよーという方も楽しんでいただけると思いますので、是非！