2023-12-02 / 定期実行のジョブがコケたらissueを作りたい

[kachick]

Nix で環境自体の依存関係を固めても、その先のライブラリやらの依存性解決でコケることがある
Rubyに関しては https://github.com/nix-community/bundix というのがあるし、 npm とかにも何かしらありそうだけど Nix 外との差異が大きくなりそうで使ってない
ので、せめてもという感じに Nix 環境を定期実行して、早めに気づこうとはしている

この手の話でいざ落ちるときは、大体大本が一つなのになんの関係性もないリポジトリにまたがって死ぬので、issue を追っかけにくいし立ち上げるのも面倒
なのでそういったときは issue の作成まで自動化したい

というのを、deno環境で使っててバージョン固定していてもたまによく落ちる esm.sh 関連依存の一部が今回も死んでてなんだろうなーと眺めてた

https://github.com/kachick/convert-color-json-between-windows-terminal-and-vscode/actions/runs/7054749641
https://github.com/kachick/depop/actions/runs/7054756921/job/19204592304

esm-dev/esm.sh#770 (comment) 後のリトライもまだ通ってないが・・・

[kachick]

同タイミングで落ちる同じ人や組織所属のスケジュールジョブは失敗理由の関連性高そうだし、そもそも各リポジトリのワークフローを都度都度更新するとか面倒なので、一斉ポーリングしてどでんとissueたてるactionが必要なのではないだろうか

ブランチとかPR単位で落ちてるものは雑に有るだろうから、デフォルトブランチを、できれば前回からの差分で追うようなのが・・・

[kachick]

今朝なんか2つも落ちてた。落ちるの自体は仕方ないというかいつか落ちるだろう前提で書いてるのをこれで拾ってる面はあるんだけど、やっぱ都度 issue 作るの面倒なのでなんかほしいな・・・

kachick/irb-power_assert#176
kachick/gwurl#5

[kachick]

全体でポーリングするのは流石にあれだし定期実行するようなのはそんなに無いので、job とか step 単位で仕込めばそれで良い気もする

[pankona]

デッドマンズスニッチを使う？ｗ

[kachick]

凄い懐かしい名前を聞いた・・・外形監視サービスのやつだよね

それはそれで便利に使えるところもあるけれど、GitHub で完結させられるならそっち優先かな～

[kachick]

同タイミングで落ちる同じ人や組織所属のスケジュールジョブは失敗理由の関連性高そうだし、そもそも各リポジトリのワークフローを都度都度更新するとか面倒なので、一斉ポーリングしてどでんとissueたてるactionが必要なのではないだろうか

これを完全に忘れて

全体でポーリングするのは流石にあれだし定期実行するようなのはそんなに無いので、job とか step 単位で仕込めばそれで良い気もする

これ書いてた

[kachick]

これもなんかちょっとした工夫でRSSリーダーへ集約みたいな事できそうな気もしつつ、そのちょっとした工夫を探すので結局それなりに手間かかりそうな気がしてきた #242

ruby の gem で head に対するCIとか cache 対象指定を間違えてた deno の integrity checkで 落ちてたんだけど、deno は原因がわかった感なので減りそうな気がしている。
ruby-head は head を考慮対象から外したほうが良い気もしつつ、 https://github.com/ruby/docker-images でほぼ master に対する動作確認が楽に出来るから前ほど大変じゃないかも

ということで一旦考えないように閉じてしまおう