ci: cargo-denyのadvisoriesだけcronでの実行にする

[qryxip]

内容

cargo-denyワークフローをlicensesとauditに分離し、後者を毎日のcron実行とする。

関連 Issue

その他

RustSecへの登録によって「何もしていないのにCIが落ちた」ケースが最近増えてきたため、ENGINEのようにcronだけで動かす方が妥当かなと思った次第です。
(もしかしたらENGINEと同様、Discordへの送信にした方がよいかもしれない)

[Hiroshiba]

ちょっと目的を整理しておけると！
目的次第ですが、どっちもcron実行・mainブランチで実行にしても良いのかも？

たしかcargo-denyをmainブランチでのテストにしてた理由は、ファイルを更新するのは大変なので、コミッターでなくメンテナが更新すれば良いようにしたかったからだった記憶。
mainブランチのテストはたまに落ちて良いという設計っぽみ。

今回のPRはadvisoriesのみmainブランチから外してcronにし、ほかはmainブランチで動かす感じですよね。
提案としては、まあどっちもcron・mainブランチで動かすようにすればよいのかな、みたいな。
（だとしたらファイルを分けなくて済むので）

追記：
あいや違うか、advisoriesだけはauditで最悪スルーしてリリースできるけど、ほかは無視するとリリースできないみたいな･･･？
だとしたらなぜファイルを分けてるかのメモコメントというか、各ファイルが何を担当しているのかわかるようにするのが良さそう！

（audit（監査）だとなぜadvisoriesだけしているのかわからない）

[qryxip]

どちらかというと、licenses (advisories以外のcargo-deny)はライブラリを追加したときに反応するので、こちらにはcron実行するメリットは無いと思った次第です。なので役割的には分離した方がよいかなと。

一方audit (advisoriesのみのcargo-deny)はライブラリの追加に関係無く反応するのが主になると思ってます。
（ライブラリを新規追加したときにそれがヤンクされていたり、脆弱性が報告されていたりのケースもまあ有り得なくはないけど、レアケースと考えてよさそう）

advisoriesをリリースで無視してよいかは、内容によりそう。極端な話「作者のアカウントが乗っ取られました。この最新バージョンはマルウェアです」は駄目だし…

[Hiroshiba]

なぁるほどです。

ちなみに「advisories以外のcargo-deny」は結構難しいあのdeny.tomlの編集が不要･･･だったりはしないでしょうか。
というのもworkflowファイルがだいぶ多くなっているので、可能なら小分けにしたくないなぁと･･･。
でも無理なら仕方なさそう！

ジャストアイデアでやるべきかはわかりませんが、「advisories以外のcargo-deny」をtest.ymlに移しちゃって、mainブランチ以外では動かないようにするのもあり･･･かも･･･？