Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GitHub Actionsの構成がおかしいぜ?という話 #1486

Open
berryzplus opened this issue Dec 12, 2020 · 11 comments
Open

GitHub Actionsの構成がおかしいぜ?という話 #1486

berryzplus opened this issue Dec 12, 2020 · 11 comments
Labels
CI appveyor など CI 関連 【ChangeLog除外】 GitHub Actions GitHub Actions関連

Comments

@berryzplus
Copy link
Contributor

問題内容

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

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

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

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

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

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

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

再現手順

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

再現頻度

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

問題のカテゴリ

  • ビルドの問題
    • GitHub Actions

環境情報

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

スクリーンショット

本文を参照。

@k-takata k-takata added the CI appveyor など CI 関連 【ChangeLog除外】 label Dec 12, 2020
@ghost
Copy link

ghost commented Dec 13, 2020

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

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

@berryzplus
Copy link
Contributor Author

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

@berryzplus berryzplus added the GitHub Actions GitHub Actions関連 label Dec 14, 2020
@ghost
Copy link

ghost commented Dec 17, 2020

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

  1. なぜVS2017を使わないのか
  2. なぜテストを実行していないのか
  3. なぜ毎回ヘルプのビルドを行うのか
    • 不明(インストーラのビルドに必要なので、その前に実行しておく必要はある)。
      • Azpも毎回実行しているように見えました。
    • AppVeyorに倣ってBuildChmジョブを追加し、そのジョブの生成物をactions/download-artifactを使って取得すればいいと思います(この場合、MSBuildジョブはBuildChmジョブの完了を待つか、インストーラのビルドを別ジョブとして独立させる必要があります)。
  4. 公開しないはずのDebug版インストーラをなぜビルドするのか
    • CI の成果物をアップするのを Release 版に限定する #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
Copy link
Member

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

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

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

@berryzplus
Copy link
Contributor Author

独自研究が一旦完成しました。
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
Copy link

ghost commented Dec 18, 2020

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

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

@berryzplus
Copy link
Contributor Author

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

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

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

@berryzplus
Copy link
Contributor Author

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

@berryzplus
Copy link
Contributor Author

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

  • 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
Copy link
Contributor Author

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

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

@berryzplus
Copy link
Contributor Author

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

@berryzplus berryzplus reopened this Jan 12, 2021
@ghost ghost self-assigned this Feb 24, 2022
@ghost ghost removed their assignment May 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI appveyor など CI 関連 【ChangeLog除外】 GitHub Actions GitHub Actions関連
Projects
None yet
Development

No branches or pull requests

2 participants