download_test.ymlが必ず落ちることがあるので運用をどうするか

[Hiroshiba]

内容

download_test.ymlではダウンローダーが想定されている同梱物を全て含んでいるかをテストしています。
今のところプッシュの頻度でテストが行われています。

一方同梱物をビルドする機構はリリースするたびに実行されます。
そのため、同梱物が変更された場合、リリース前にプッシュされたものは全てテストが落ちることになっています。
このテストの運用方法を考えたいです。

実現方法

• 運用方法案１：プッシュされるたびにテストではなく、リリースされるたびにテストにする
  • 利点：プッシュ時にテストが落ちなくなる
  • 欠点：ダウンローダーにバグがあっても気づくのはリリースのタイミング
• 運用方法案２：プッシュされるたびにテストにし、テストが落ちていたとしても無視する
  • 利点：ダウンローダーにバグがあった場合に気づける
  • 欠点：テストが落ちているのにマージしないといけない
• 運用方法案３：download_testが落ちてもなかったことにできる機能を入れる（thx @qryxip !）
  • 利点：上記２つの案の欠点をなくせる
  • 欠点：実装・運用を考える必要がある

個人的には別に超大事なことではないと思っているので、ちょっと雑な運用方法でもいいかなと思ってます。
テストが落ちているのにマージするという運用は何か他のミスを誘発しかねないので、もし１か２で倒すとしたらテストの頻度を下げる案１の方かなと思ってます。

その他

[Hiroshiba]

@qryxip さんから運用方法案３の案をいただきました。
とりあえずテストが落ちていてもマージする案２を採用しておいて、いずれ案３を実装するとかが良いかもとか思いました。

[Hiroshiba]

0.14.5のリリースを作って分かったのですが、過去のバージョンのprereleaseが最新になってしまって、mainブランチのものと整合性が取れずにテストが落ちることがありそうです。
なんか根本的に問題がある気がしました。

ダウンロードテストでやりたいのは2つあって、1つがmainブランチ/プルリクエストのダウンロードコードが正しいことの確認、もう一つがreleaseされた物が正しいかどうかの確認だと思います。
mainブランチのテストが落ちっぱなしなのは本当にダメな時に気づけないので頑張って解決が必要に感じます。

ちょっと色んな手を考えてみたのでどの方針が良さそうかご意見いただけると嬉しいです 🙇 @y-chan @qryxip

1. mainブランチが更新されたたびにリリースする
   • 👍 ダウンロードコードとリリース物を両方テストできる
   • 🤔 Github Actionにそこそこの負荷がかかる
   • 🤔 すぐには作れない
2. 製品版のリリースがあるたびにmainブランチでプレビュー版をリリースする
   • 👍 今すぐ実行可能
   • 🤔 手間がかかる
3. ダウンロードテスト用のモックを作る
   • 👍 プルリクエスト含めダウンロードコードがテストできる
   • 🤔 すぐには作れない
   • 🤔 モックが正しいかどうかをテストする機構が必要かも
4. リリース時のみテストするようにする
   • 👍 テストが落ちっぱなしにならない
   • 👍 今すぐ実行可能
   • 🤔 ダウンロードコードがおかしくなっていても気づくのが遅れる
5. download_testが落ちてもなかったことにできる機能を入れる
   • 👍 プルリクエストのダウンロードコードがテストできる
   • 🤔 mainブランチのダウンロードコードが落ちるのはどうにもできない

個人的には、ダウンロードテストがそこそこに実行できる1の方法が良いのかなとか思いました！
ダウンロードする対象を変えるプルリクエストのテストが落ちますが、これは @qryxip さんの提案の5を足せば良いかなと！
（プラスで3もあればいいけど大変そう。）

それはそれとしてmainブランチのテストが落ちているのは今すぐ何とかすべきだと思うので、プレビュー版をリリースしようと思います。

[Hiroshiba]

1. mainブランチが更新されたたびにリリースする

これ、製品版のリリースはメンテナの認可が必要なので、毎回リリースは厳しいことに気づきました･･･ 😇
なので

2. 製品版のリリースがあるたびにmainブランチでプレビュー版をリリースする
3. download_testが落ちてもなかったことにできる機能を入れる

この2つの併用が現実的な気がしました。