appveyor のビルドで削れるものがないか検討する

[m-tmatma]

@KENCHjp
sakura-editor/management-forum#14 (comment)

appveyorのDebugモジュールって利用用途ありますでしょうか？、というのも全体のコンパイル時間が25分ぐらいになってて、キューに２つ溜まると、コミット後１時間近く待つことに。。。
例えば、Debugだと、インストーラーは不要とかありますか？
必要ならば特に無理に削る必要はないとおもいますが。

@m-tmatma
sakura-editor/management-forum#14 (comment)

例えば、Debugだと、インストーラーは不要とかありますか？

バイナリはいらないですが、コンパイルはしときたいです。
インストーラーや cppcheck はいらないと思います。

@KENCHjp
sakura-editor/management-forum#14 (comment)

インストーラーや cppcheck はいらないと思います。

了解です、マストじゃないですが、Debugや、win32で重複して実行しなくてもいいものは整理してもいいかもですね。

25分はそこそこ長いかと思ってますので(技術屋的に定量的な表現ではないのは恐縮ですが）

[berryzplus]

なんとなくのイメージです。

platform	config	build	cpp check	unit test	function test	.zip	.exe
Win32	Debug	○	○	○	×	○	×
Win32	Release	○	×	×	○	○	○
x64	Debug	○	○	○	×	○	×
x64	Release	○	×	×	○	○	○
MinGW64	Debug	○	×	○	×	×	×
MinGW64	Release	○	×	×	×	×	×

現状は Win32/x64 のみで、表の全部に○が付いてる状態だと思います。
（function testって１個も作ってませんけどｗ）

[m-tmatma]

https://ci.appveyor.com/project/sakuraeditor/sakura/build/1.0.755 のビルドで実行時間を調べた。

	Win32 Release	Win32 Debug	x64 Release	x64 Debug
build-sln.bat	0:01:13	0:01:18	0:01:59	0:01:47
build-chm.bat	0:00:05	0:00:06	0:00:05	0:00:06
build-installer.bat	0:00:02	0:00:03	0:00:02	0:00:03
install-cppcheck.bat	0:00:02	0:00:01	0:00:02	0:00:02
run-cppcheck.bat	0:01:18	0:01:19	0:01:22	0:01:23
zipArtifacts.bat	0:00:06	0:00:14	0:00:07	0:00:15
create-project.bat	0:00:49	0:00:49	0:00:51	0:00:52
build-project.bat	0:00:42	0:00:29	0:00:42	0:00:30
run-tests.bat	0:00:00	0:00:00	0:00:00	0:00:00

トータル 0:18:44
だだターゲット OS 再起動とか含むのでもっと長いはず。

↓ 以下はログファイル

LOG.zip

[m-tmatma]

計算に使用した excel を添付

実行時間.xlsx

[berryzplus]

release 版の cppcheck と unit test を削れば 6 分くらいの節約になりますね。

[m-tmatma]

cppcheck を appveyor でやるのをやめて travis CI でやるようにできれば、 5 分30秒ほど削れる。

[m-tmatma]

create-project.bat は Release/Debug で実行しているが、一回でいいので、
単体テストを Release あるいは Debug の appveyor インスタンスで
両方のビルドとテストをやるようにすれば処理内容を変えずに 2 分削れる。

[beru]

create-project.bat で googletest を取得していますが、ユニットテストフレームワークを Catch2 に切り替えると色々と捗ると思います。

[m-tmatma]

create-project.bat で googletest を取得していますが、ユニットテストフレームワークを Catch2 に切り替えると色々と捗ると思います。

何がどう改善しますか?
https://github.com/catchorg/Catch2 も同様に cmake を使っているようですが。

[beru]

何がどう改善しますか?

header-only で 単一ファイルにされたものも公開されているので、予め sakura のリポジトリに登録してしまえば create-project.bat 内で取得する手間が省けます。

https://github.com/catchorg/Catch2 の The latest version of the single header can be downloaded directly using this link と書かれたリンクで落とせるファイルがそれです。

あと header-only なので GoogleTest のプロジェクトが生成されなかったりでトータルの実行時間が恐らく減るんじゃないでしょうか。

他には modern なのであまり色々なマクロを使い分けなくてもテストが自然な書き方で記述出来るというのは大きな利点だと思います。これはこのIssueでの議論の範疇外かもしれませんが…。

[m-tmatma]

↑ 別チケットで上げていただけますか？
googletest より優れているのであれば、乗り換えてもいいと思います

[berryzplus]

単体テスト書いてみて分かったんですがGoogletestの組込は不完全っぽいです。本来使えるはずのvs連携機能が使えなかったのでデバッグが手間でした。

ヘッダは軽いので速度は速いと思いますがvs連携がなさそうなのが気になってます。まぁ、今と同じなんですが。

[m-tmatma]

単体テスト書いてみて分かったんですがGoogletestの組込は不完全っぽいです。本来使えるはずのvs連携機能が使えなかったのでデバッグが手間でした。

vs連携機能 とは何を意味してますか? visual studioでのステップ実行ですか?
現状デフォルトで test1 のプロジェクトがスタートアッププロジェクトに設定
されていないので、そのままではデバッグ実行できませんが、

test1 をスタートアッププロジェクトに設定したらステップ実行できます。

※ 単体テストのデバッグ方法の markdown を書こうと思います。

[m-tmatma]

create-project.bat を呼ぶと visual studio のソリューションが
tests\build\sakura-unittest.sln にできるのでそれを VS で開いて、
test1 をスタートアッププロジェクトに設定したらステップ実行できます。

[beru]

↑ 別チケットで上げていただけますか？
googletest より優れているのであれば、乗り換えてもいいと思います

#433 を作成しました。確認お願いします。

[beru]

スタートアッププロジェクトの設定ですが、

https://stackoverflow.com/a/37994396/4699324

によると、CMake のバージョン 3.6 以降で指定出来るようです。

[berryzplus]

デバッグ実行は出来てます。Ctrl T D とか出来ませんでしたけど。本来はテストエクスプローラにテスト結果をリンク表示させる機能とかがあります。
https://github.com/berryzplus/githubpr
動作確認目的で前に作ったCmakeプロジェクトでは出来てたので、なんか違うんだと思います。

[m-tmatma]

Google test 用の vs プラグインをインストールしたら連携してくれた気がします。

[berryzplus]

デフォルトで入るはず。日本語バグってるけど。

[m-tmatma]

単体テストのビルドが遅いが、googletest 自体のビルドをしないように
ビルド済みバイナリを使うことができれば高速化できないだろうか?

#434 で https://github.com/catchorg/Catch2/blob/master/docs/cmake-integration.md#top を
見てて思った。

https://cmake.org/cmake/help/v3.10/module/FindGTest.html

ビルド済みバイナリで以下の問題が発生しなれば、ビルド済みバイナリを
使ってもいいのかもしれない。
#181 (comment)

[m-tmatma]

時間かかる問題は何も変わってないはず

[berryzplus]

すみません。誤操作です。

iPhone で自覚なくボタン押し間違ってたようです。

何かしら処置するまで継続の認識です。

[berryzplus]

cppcheck を appveyor でやるのをやめて travis CI でやるようにできれば、 5 分30秒ほど削れる。

これスルーされてる気がしますが travis CI の検討ってどっかでやりましたっけ？

https://ja.wikipedia.org/wiki/Travis_CI
https://travis-ci.org/ ←下の方に Mac, Linux, and iOS support ってあるのでWinは駄目ぽい？

しかしpro版のほうにはこんな情報が公開されていて、普通にwindowsビルドできそうな気配とか。
https://docs.travis-ci.com/user/reference/windows/

azure pipelineを使う使わないの話は置いておいて、cppcheckやテストをappveyor以外の環境に退避させる方法も、検討の余地はある気がします。

[ds14050]

豆知識。ローリングビルドというオプションでブランチ毎 PR 毎の最新コミットしかビルドしなくなる。古くなったコミットはビルド中でもキャンセルされる。

[berryzplus]

ローリングビルドというオプションでブランチ毎 PR 毎の最新コミットしかビルドしなくなる。古くなったコミットはビルド中でもキャンセルされる。

たまたまPRのタイミングが被ったら、ビルドが後勝ちになってしまう危険を感じました。
意図的にはやんないと思いますけど、それでビルドキャンセルされたらショックｗ

[k-takata]

たまたまPRのタイミングが被ったら、ビルドが後勝ちになってしまう危険を感じました。

ブランチ毎 PR 毎なのでそれはないはず…

[m-tmatma]

豆知識。ローリングビルドというオプションでブランチ毎 PR 毎の最新コミットしかビルドしなくなる。古くなったコミットはビルド中でもキャンセルされる。

そのオプションは認識していますが、あえて有効にはしていないです。

理由は、必要のなくなったビルドは appveyor 上で手動でキャンセルできるので、
複数 push した場合に全部の commit でビルドできることを優先させているためです。

[m-tmatma]

#432 を検討し始めました。

[berryzplus]

google test を自前でビルドするのをやめる

という選択もありそうです。

現状でサクラエディタが対応しているビルド環境は vs2017 と MinGW64 ですが、
この 2環境 にかんしていえば、ビルド済みバイナリのパッケージを取得する方法があります。

環境	gtest取得方法
vs2017	Nuget パッケージ
MinGW	pacman パッケージ

vs2017 は packages.config を用意してビルド前に nuget コマンドを叩けばいけそう。

<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="Microsoft.googletest.v140.windesktop.msvcstl.static.rt-static" version="1.8.0" targetFramework="native" />
</packages>

MinGW64 はappveyorに記述を追加すればいけそう。

install:
- cmd: |
    C:\msys64\usr\bin\bash --login -c "pacman -S --noconfirm mingw-w64-x86_64-gtest"

[m-tmatma]

appveyor で各種処理を実行するのをやめました。

#833 適用前 https://ci.appveyor.com/project/sakuraeditor/sakura/builds/23597175 → 48 min 57 sec
#833 適用後 https://ci.appveyor.com/project/sakuraeditor/sakura/builds/23615895 → 25 min 22 sec

単体テストも azure pipelines に移すことはできるかもしれない

[m-tmatma]

google test を自前でビルドするのをやめる

という選択もありそうです。

に関しては #796 で検討中

[berryzplus]

#983 対応により、現在appveyorのビルドタスク数は5件になりました。
何かを削らないといけない状況は回避されたと思うので、この issue は閉じてしまいます。