GitHub Actionsの構成がおかしいぜ？という話

[berryzplus]

問題内容

GitHub Actionsの構成がおかしいぜ？という話をします。

いまこうなっています。MsBuildというビルドタスクを4多重で走らせています。

ちょっと前から「おかしいな...」と思っていたんですが、やはりおかしいです。

これは、C/C++のビルドが正常に通ることを確認する目的のタスクだと認識しています。

■疑問点 何故visual studio 2017でのビルドを行っていないのか。 何故、生成されて実行可能なテストプログラムを実行していないのか。 何故「挙動が不安定で成功率が高くないHTMLヘルプのビルド」を毎回行わないといけないのか。 何故「不要である」と合意してるはずの「デバッグ版インストーラー」を作っているのか。

■おいらなりの解釈 とりあえずで作ったものだから、あんまり細かいことは考えてなかった、ということかと思います。

ぶっちゃけ、GitHub Actionsのことはよく知らないのでどうしたらいいか分かっていないんですが、Azure DevOpsでできることはほぼ似たようなことができるっぽいので（しかも、GitHubとの連携はより強力っぽいので）正常化することによるメリットは大きいように思います。

再現手順

GitHUbActionsに組み込まれているので、pull-requestかマージを行うと再現します。

再現頻度

GitHUbActionsに組み込まれているので常に再現します。

問題のカテゴリ

• ビルドの問題
  • GitHub Actions

環境情報

GitHub Actionsの話なので、ローカル実行環境は関係ありません。

スクリーンショット

本文を参照。

[ghost]

何故「不要である」と合意してるはずの「デバッグ版インストーラー」を作っているのか。

この点、確認したところ不具合に見えましたので、修正PRを提出させていただきました → #1487 ご確認願います。

[berryzplus]

成果物(=Artifacts)としてダウンロードできるファイルを作成しないようにする、という意味で #1487 のタイトルは間違っとらんと思うのですが、ここで指摘したのは「公開しないならビルドすら不要じゃね？」なのでちょっと違います・・・。

[ghost]

appveyor_testブランチを見た感じ、今更なコメントなのかもしれませんが、書き残しておきます。

1. なぜVS2017を使わないのか
   • 現在のホストランナー（windows-latest）ではVS2017が含まれないので使えません。
     • 出典：https://github.com/actions/virtual-environments/blob/main/images/win/Windows2019-Readme.md#visual-studio-enterprise-2019
   • ホストランナーをwindows-2016に変更すれば使えます。
     • 出典：https://github.com/actions/virtual-environments/blob/main/images/win/Windows2016-Readme.md#visual-studio-enterprise-2017
     • Azpも実行環境にVS2017ならVS2017-Win2016、VS2019ならwindows-2019と指定を分けているので、同様に対応すればよいと思います。
2. なぜテストを実行していないのか
   • 不明（build-all.batを基にして、それに相当するものとして構築したため？）。
   • Azpに倣ってbuild-bmp-tools.batとrun-tests.batを実行するよう、ステップを追加すればよいと思います。
     • ただし、現状AppVeyorではbuild-bmp-tools.batは実行されていません。
     • build-bmp-tools.batは #1130 で追加されました。
3. なぜ毎回ヘルプのビルドを行うのか
   • 不明（インストーラのビルドに必要なので、その前に実行しておく必要はある）。
     • Azpも毎回実行しているように見えました。
   • AppVeyorに倣ってBuildChmジョブを追加し、そのジョブの生成物をactions/download-artifactを使って取得すればいいと思います（この場合、MSBuildジョブはBuildChmジョブの完了を待つか、インストーラのビルドを別ジョブとして独立させる必要があります）。
4. 公開しないはずのDebug版インストーラをなぜビルドするのか
   • #1403 でインストーラの公開をやめることを考えるとき、結果としてビルドする必要もなくなることに気づかなかったのではないでしょうか。
   • Azpでもビルド自体は実行されています。
   • 公開しない以上、止めても良いと思います。

ちなみに、AppVeyorはbuild-all.bat経由で実行される関係で、zipArtifacts.batは常に実行されています。 （このため、Debug版成果物を作成するものの、アップロードはされないという状態のようです。） 一方、GHAとAzpはzipArtifact.batをRelease版に限定しているので、Debug版のzip成果物すべての作成自体が行われません。 これにより、AzpにはDebug版とMinGWビルドでアップロードする成果物がないことを示すwarningが出ています。

とりあえず、現状のジョブにrun-tests.batを実行するステップだけでも追加しませんか？ これで実行されるタスクが（BuildChmが独立していない点を除けば）AppVeyorと揃うと思うのですが。

[k-takata]

3. なぜ毎回ヘルプのビルドを行うのか

逆に、AppVeyor でわざわざジョブを分けているのは、Windows を日本語ロケールにするために再起動が必要で、それが時間がかかる上に不安定だからだと思っていました。

GHA/Azp では再起動ができなかった訳ですが、leproc を使うことで再起動せずにできるということが分かったため、そのまま同じジョブでビルドすることにしました。ヘルプコンパイラ自体が不安定なのは困りましたが…。 エラーになったときは1回リトライするようにしましたが、数回リトライしてもいいかもしれません。

[berryzplus]

独自研究が一旦完成しました。 https://github.com/berryzplus/sakura/actions/runs/428172351

1. 最初に、ファイルエンコードチェックを走らせる
2. 並行ビルドでMsBuild、BuildChm、MinGWビルドを走らせる
3. MsBuildとBuildChmが成功した場合のみ、installerビルドを走らせる

元々作っていた多種多様なzipファイルは、「ビルドが正常に行えるか？」を確認する上では不要と判断しました。また、GitHub Actionsでは成果物をアップロードすると勝手に再圧縮されるのでハッシュファイルを自前で生成してやる必要もないと判断しました。色々調べたり試したりした感じ、Windows環境を使う場合はGitHub Actions ではなく Azure DevOps を使ってSonarCloudするのが普通っぽいです。

これを、どう取り込んでいくかは考え中です。

[ghost]

24d56b7557f8394c74f938e3e81fd7a702945cb2 「MinGWテストのビルドが無理」

ログを見た感じでは、MinGW-w64-gtestをインストールしていない気がします。 参考：https://github.com/sakura-editor/sakura/blob/master/ci/azure-pipelines/template.steps.install-mingw-w64-gcc.yml

[berryzplus]

24d56b7 「MinGWテストのビルドが無理」

ログを見た感じでは、MinGW-w64-gtestをインストールしていない気がします。 参考：https://github.com/sakura-editor/sakura/blob/master/ci/azure-pipelines/template.steps.install-mingw-w64-gcc.yml

ちょっと対応してみます。

[berryzplus]

成果物のファイル名が気に入らんのですが、MinGWテストは復活できました。 https://github.com/berryzplus/sakura/actions/runs/430820612

[berryzplus]

せっかくなのでレス返しておきます。

• Azpも実行環境にVS2017ならVS2017-Win2016、VS2019ならwindows-2019と指定を分けているので、同様に対応すればよいと思います。

GitHub Actions がサポートする windows OS は公式には1種類らしいです。 https://docs.github.com/ja/free-pro-team@latest/actions/reference/workflow-syntax-for-github-actions#jobsjob_idruns-on

サポートが明言されていないのは、visual studio 2017のベースラインサポートが2021年1月で終了するからなのかな？と思いました。 https://docs.microsoft.com/ja-jp/visualstudio/releases/2019/servicing

よくよく考えてみると、vs2015はまだメインストリームサポート期間中で、vs2013も延長サポート期間中なんですが、こいつらをサポートするCloud-CIを見かけた記憶がない気がします。

だから「公式にはvs2017がサポートされてないんで、といりぜず最新版でやってる」という解釈で納得した感じです。

[berryzplus]

成果物(=Artifacts)としてダウンロードできるファイルを作成しないようにする、という意味で #1487 のタイトルは間違っとらんと思うのですが、ここで指摘したのは「公開しないならビルドすら不要じゃね？」なのでちょっと違います・・・。

「公開しないならビルド不要」は、必ずしも妥当な理屈とも言えないっす。 ビルド自体が目的（＝ビルドが通るかどうかを見たい！）な場合もある気がしてきました。

[berryzplus]

間違って閉じたことに気付きました。