メインで使うCI環境をAppveyorからGitHub Actionsに変更したい

[berryzplus]

(必須) やりたいこと(=実現したいこと)

メインで使うCI環境をAppveyorからGitHub Actionsに変更したいです。

変更したい理由は、 #1680 であげたように Appveyor はビルドジョブの並列実行ができないためです。
ビルドが遅いこと自体に関しては #1686 で軽減措置を実施済みです。

(省略可) 解決手段の提案

どのCI環境がメイン？というのは、リリース時にどのCIビルドの成果物をGitHub Releaseに入れるか？ということで、
現状は「手動で成果物をアップロードしてリリースする」なので、
どこかで「決めました！」と宣言したら「終わり」だと思っています。

ただ、現状はリリースバージョンのバージョン表記に Appveyor のビルド番号 を含めるルールになっているので、CI環境を変更するならルールを変更する必要があります。

バージョン表記については #168 とかで議論されています。

「いまいま」で結論を出す話でもないと思うんですけど、
末尾の数値に「累積コミット数」を使う方式に戻すのがいいんじゃないかと思っています。
こうすると、どの環境でビルドしても同じバージョン番号になるメリットがあります。

-	dev版	リリース版
現在	v2.4.2.3333 dev	v2.4.2.4444
提案	v2.4.2-3333 GHA	v2.4.2+4444 GHA

TODO

• バージョンを組み立てるバッチgithash.batの修正。
• CI環境のドキュメント修正
• (やらなくても可) 「CI/CD」の「CD」部分を組んでみる。

issueクローズ条件

• githash.bat修正をマージすること。

[ghost]

個人的には賛成ですが、今のところ次の差異があります。

• parse-buildlog.bat から呼ばれる二つの Python スクリプトが利用できない
  • 詳細：GitHub Actions の環境変数をビルドで利用できるようにする #1669 (comment)
• 単体テスト（ tests/run-tests.bat ）を実施していない

単体テストは追加すればいいだけの話なのでよいとして、 parse-buildlob.bat の取り扱いをどうするか悩みます。
（スクリプトなどを修正して AppVeyor 以外でも使えるようにするか、現状で「活用実績がない」ことを理由に廃止するか。）

githash.bat にある Azure Pipelines の環境変数設定は yml ファイルに追い出すという認識でいいんでしょうか？

[berryzplus]

また、もうみなさんご存じだと思いますが、既に visual studio 2019 の後継バージョンがアナウンスされています。
https://visualstudio.microsoft.com/ja/vs/preview/vs2022/

Appveyorを使い続ける理由の一つに、 vs2017 に公式に対応しているCI環境が Appveyor と Azure Pipelines だけっていうのもありました。絶対 vs2017 じゃないとダメか？というとそうではないと思っています。しかし、だからといって「バージョン指定なし」にして「俺のC++コンパイラは生涯BCC5.5だけだ！」のように誰得な漢心（オトコゴコロ）に付き合うつもりもないです。

[berryzplus]

個人的には賛成ですが、今のところ次の差異があります。

• parse-buildlog.bat から呼ばれる二つの Python スクリプトが利用できない

  • 詳細：#1669 (comment)

• 単体テスト（ tests/run-tests.bat ）を実施していない

単体テストは追加すればいいだけの話なのでよいとして、 parse-buildlob.bat の取り扱いをどうするか悩みます。
（スクリプトなどを修正して AppVeyor 以外でも使えるようにするか、現状で「活用実績がない」ことを理由に廃止するか。）

parse-buildlog.batの位置づけは良く分からないです。
「ビルドログを見やすくする」が目的だと思いますが、何のために見やすくするのかが不明っす。
※普通は、警告を見やすくして対処するためにやりますが、visual studioのエラー一覧より見やすいか微妙。

単体テストを実行するためにバッチファイルが必要なのはAppveyorの特性です。
※必ずしも bat である必要はありませんが、実行スクリプトが必要です。

Azure PipelinesやGitHub Actionsではテスト実行にスクリプトを要求しません。

githash.bat にある Azure Pipelines の環境変数設定は yml ファイルに追い出すという認識でいいんでしょうか？

はい、たぶんそのほうが分かりやすくなると思います。

---

各CIの特性、得意分野をどこかでまとめたほうが話をしやすいのかも、と思ったり思わなかったり・・・。

[ghost]

お返事いただきありがとうございます。

parse-buildlog.batの位置づけは良く分からないです。
「ビルドログを見やすくする」が目的だと思いますが、何のために見やすくするのかが不明っす。
※普通は、警告を見やすくして対処するためにやりますが、visual studioのエラー一覧より見やすいか微妙。

フィルター機能ならVSのエラー一覧にもありますし、今一つ目的がつかめていません。
なお、このスクリプトは正規表現を修正しなければVisual Studio 2019のログを扱えず、Excelブックの出力もopenpyxlのインストール先を変えなければできません。ただ、openpyxlのインストール先変更は「Pythonスクリプトのコンパイルチェック」を行うジョブにも影響するので、手を出しづらいです。
今後の扱いを検討する必要があると思います。

余談：そういえば、サポート終了から半年経ったPython 2.7系用のコードとパイプラインジョブは除去したいですね。

単体テストを実行するためにバッチファイルが必要なのはAppveyorの特性です。
※必ずしも bat である必要はありませんが、実行スクリプトが必要です。
Azure PipelinesやGitHub Actionsではテスト実行にスクリプトを要求しません。

run-tests.batをワークフローに追加して、とりあえずすべてのCIで実施はできている状態にしたいです。
もちろん「スクリプトを使わない方法」でも良いです。

githash.bat にある Azure Pipelines の環境変数設定は yml ファイルに追い出すという認識でいいんでしょうか？

はい、たぶんそのほうが分かりやすくなると思います。

👍

[ghost]

（ #168 ・ #1680 ともにcloseされていますし、参考ということで転記させてください。）

#1680 (comment)

appveyorを止めるには #168 を更新する必要があります。

v.2.4.aa.bbbb
というバージョン番号のうち、
bbbb部分にappveyorのビルド番号（通し番号）を使っています。

妥当な代案を思いつかないので「変えましょう」とも言えず放置してる感じです。

可能な方法
・git リポジトリの累積コミット数を表示する（SvnのRev相当
　メリット：Appveyor/Azure Pipelines/GitHub Actionsでビルド番号が揃う。
　デメリット：ビルドにかかる時間が十数秒延びるかも。なんかダサい。

git log --oneline --no-merges | wc -l で秒で取れるらしいです。アリだと思います。