GitHub Actionsの構成がおかしいぜ?という話をします。
いまこうなっています。MsBuildというビルドタスクを4多重で走らせています。

ちょっと前から「おかしいな...」と思っていたんですが、やはりおかしいです。
これは、C/C++のビルドが正常に通ることを確認する目的のタスクだと認識しています。
■疑問点
何故visual studio 2017でのビルドを行っていないのか。
何故、生成されて実行可能なテストプログラムを実行していないのか。
何故「挙動が不安定で成功率が高くないHTMLヘルプのビルド」を毎回行わないといけないのか。
何故「不要である」と合意してるはずの「デバッグ版インストーラー」を作っているのか。
■おいらなりの解釈
とりあえずで作ったものだから、あんまり細かいことは考えてなかった、ということかと思います。
ぶっちゃけ、GitHub Actionsのことはよく知らないのでどうしたらいいか分かっていないんですが、Azure DevOpsでできることはほぼ似たようなことができるっぽいので(しかも、GitHubとの連携はより強力っぽいので)正常化することによるメリットは大きいように思います。
GitHUbActionsに組み込まれているので、pull-requestかマージを行うと再現します。
GitHUbActionsに組み込まれているので常に再現します。
GitHub Actionsの話なので、ローカル実行環境は関係ありません。
本文を参照。
何故「不要である」と合意してるはずの「デバッグ版インストーラー」を作っているのか。
この点、確認したところ不具合に見えましたので、修正PRを提出させていただきました → #1487
ご確認願います。
成果物(=Artifacts)としてダウンロードできるファイルを作成しないようにする、という意味で #1487 のタイトルは間違っとらんと思うのですが、ここで指摘したのは「公開しないならビルドすら不要じゃね?」なのでちょっと違います・・・。
appveyor_testブランチを見た感じ、今更なコメントなのかもしれませんが、書き残しておきます。
windows-latest)ではVS2017が含まれないので使えません。windows-2016に変更すれば使えます。VS2017-Win2016、VS2019ならwindows-2019と指定を分けているので、同様に対応すればよいと思います。build-all.batを基にして、それに相当するものとして構築したため?)。build-bmp-tools.batとrun-tests.batを実行するよう、ステップを追加すればよいと思います。build-bmp-tools.batは実行されていません。build-bmp-tools.batは #1130 で追加されました。actions/download-artifactを使って取得すればいいと思います(この場合、MSBuildジョブはBuildChmジョブの完了を待つか、インストーラのビルドを別ジョブとして独立させる必要があります)。ちなみに、AppVeyorはbuild-all.bat経由で実行される関係で、zipArtifacts.batは常に実行されています。
(このため、Debug版成果物を作成するものの、アップロードはされないという状態のようです。)
一方、GHAとAzpはzipArtifact.batをRelease版に限定しているので、Debug版のzip成果物すべての作成自体が行われません。
これにより、AzpにはDebug版とMinGWビルドでアップロードする成果物がないことを示すwarningが出ています。
とりあえず、現状のジョブにrun-tests.batを実行するステップだけでも追加しませんか?
これで実行されるタスクが(BuildChmが独立していない点を除けば)AppVeyorと揃うと思うのですが。
- なぜ毎回ヘルプのビルドを行うのか
逆に、AppVeyor でわざわざジョブを分けているのは、Windows を日本語ロケールにするために再起動が必要で、それが時間がかかる上に不安定だからだと思っていました。
GHA/Azp では再起動ができなかった訳ですが、leproc を使うことで再起動せずにできるということが分かったため、そのまま同じジョブでビルドすることにしました。ヘルプコンパイラ自体が不安定なのは困りましたが…。
エラーになったときは1回リトライするようにしましたが、数回リトライしてもいいかもしれません。
独自研究が一旦完成しました。
https://github.com/berryzplus/sakura/actions/runs/428172351
元々作っていた多種多様なzipファイルは、「ビルドが正常に行えるか?」を確認する上では不要と判断しました。また、GitHub Actionsでは成果物をアップロードすると勝手に再圧縮されるのでハッシュファイルを自前で生成してやる必要もないと判断しました。色々調べたり試したりした感じ、Windows環境を使う場合はGitHub Actions ではなく Azure DevOps を使ってSonarCloudするのが普通っぽいです。
これを、どう取り込んでいくかは考え中です。
24d56b7557f8394c74f938e3e81fd7a702945cb2 「MinGWテストのビルドが無理」
ログを見た感じでは、MinGW-w64-gtestをインストールしていない気がします。
参考:https://github.com/sakura-editor/sakura/blob/master/ci/azure-pipelines/template.steps.install-mingw-w64-gcc.yml
24d56b7 「MinGWテストのビルドが無理」
ログを見た感じでは、MinGW-w64-gtestをインストールしていない気がします。
参考:https://github.com/sakura-editor/sakura/blob/master/ci/azure-pipelines/template.steps.install-mingw-w64-gcc.yml
ちょっと対応してみます。
成果物のファイル名が気に入らんのですが、MinGWテストは復活できました。
https://github.com/berryzplus/sakura/actions/runs/430820612
せっかくなのでレス返しておきます。
- 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がサポートされてないんで、といりぜず最新版でやってる」という解釈で納得した感じです。
成果物(=Artifacts)としてダウンロードできるファイルを作成しないようにする、という意味で #1487 のタイトルは間違っとらんと思うのですが、ここで指摘したのは「公開しないならビルドすら不要じゃね?」なのでちょっと違います・・・。
「公開しないならビルド不要」は、必ずしも妥当な理屈とも言えないっす。
ビルド自体が目的(=ビルドが通るかどうかを見たい!)な場合もある気がしてきました。
間違って閉じたことに気付きました。