10日目です。寒くなって体調を崩しがちであり、はかどっていませんが、今年中のアドベントカレンダー完遂を目指します。 https://adventar.org/calendars/8021
最近、自身の github には何もアップできていないのですが（いろいろに追いつくのでやっと。。。）、仕事場だと github actions を触る機会があるので、メモがてら個人的にもやもやしているところを残しておきます。
Github Actions 自体のテストをどう担保するか
ローカルでもCIでもいいんですが、github actions 自体のテストってそもそもどうやるのが正解なんだろう？と思いました。 人が少ないうちは push して event 飛ばしてデバッグとかでもいいのですが、大きくなるとそうも言ってなられないですし、OSSとかはより顕著な気がします。
act もいいけど、以前の経験的に github actions のためだけにセットアップするのはやや重すぎでは？ と思っていて、よりよい方法を調べなきゃなーと思っているところです。
これを楽にやれると、参入障壁が下がるのでチームメンバーが触れやすい環境になるのかなと思います。
Shell Script vs 高級プログラミング言語
どちらもメリット・デメリットがあります。
Shell Scrtiptの場合、大体のOSに入っているので動作環境をあまり気にすることがない、というメリットがあります（GNU系とBSD系で微妙に振る舞いが違うものがあるが…）。 一方で、Shell Scriptは複雑なことが苦手であるうえ、たぶん日常的にShell Scriptをゴリゴリ書いてる人は体感少な目なので、運用保守観点でこれでいいのか？ と思うシーンが多いです。
高級プログラミング言語の場合は柔軟な起債が可能であるというメリットがあります。 一方で、高級プログラミング言語の場合は、その言語の動作環境を担保せねばならず、検証するプロダクトで書いている言語に引っ張られるところです（そしてそれを置くのも微妙という気になる）。 Pythonで書いたほうが早いものをほかの言語で実装するみたいなシーンとかはあまり考えたくはないです。
どちらも一長一短あるので、微妙な感じではあります。 個人としてはどちらも選択肢ではあるので、一概に答えずらい問題だなと思ってます。
google/zx： A tool for writing better scripts とかでかくてもありますが、うーん… oilshell/oil： Oil is a new Unix shell. It's our upgrade path from bash to a better language and runtime. It's also for Python and JavaScript users who avoid shell! でもうーん… （自分はいいとして、人に対しての学習コストに対して）
外部スクリプトに分ける vs workflow の中に書ききる
これはテストにもかかわってきますが、どっちがいいんでしょうね。 単体で実行できる外部スクリプトに変数を渡すのがいいような気はしています。 ただ、管理しなければいけないファイルの増加や、workflowの中での event と直結してるほうが分かりやすいというのもあり、一概にそうすべきなのか？ が分からないなと思いました。
runner machine セットアップ
About self-hosted runners - GitHub Docs を使っているとあるあるなんですが、マシンスペックとかスケールとかはいろいろ課題感があります。
ちょっとこの辺は下調べが足りてない感じがするので（随時マシン起こせばよくない？ とかタスクとして実行すれば？ とかいろいろ）また調べてみてから考えようかなーって感じで、学びどころなのかなと思っています。
どう教えるか
チュートリアルだけだとサービスに即した形で教えていくのがなかなかむずいかも。
まとめ
そんな感じのことを仕事では考えていたりします。 最近そういう話をしたり、考えたりするのもできていなかったのですが、もやもやしていたので知見のある人がいたらぜひ教えてほしいです（ベストプラクティスとかそういえば追えてないので、そういうのを読んだらまとめておこうと思います）
また一つ、課題を発見してしまったな…？
