リリース時にのみ行う処理はできるかぎり減らす - プログラムモグモグ

GitHub Actionsなどでテストやリリースを自動化していると、様々なトリガーによって異なる処理を行うことはよくあることです。 例えばpushのトリガーではテストやlintを行い、tagをpushしたときはクロスビルドしてリリースする、などです。 これらの処理は内容も頻度も異なるので、ワークフローのファイルを分けることはよくあることだと思います。 私もかつてはこのようにトリガーや実行したい頻度が異なるのだから分けるのは自然なことだと考えていました。 一つのワークフローの中でトリガーによって処理を分岐させるとワークフローが複雑になるし、面倒なことが多いからです。 しかし、最近はリリース時の処理をテストと同じワークフローにまとめる方が良いと考えるようになりました。 リリースする時になって初めて動く処理が多いほど、リリースのワークフローが壊れるリスクが高まるからです。 GitHub Act

[igrep]

" リリースのためのビルド処理は、テストと同じ頻度で行いましょうということだと思います。 また、テストが通らなかったらリリースを止めたいという素朴な要件が、ワークフローがまとまっていれば簡単に達成できる"

[a-know]

たしかに