Continuous Integration for auto tests and builds

[maphew]

Set up CI to run automatic tests on the code and, if all goes well, also build binaries for release and distribution. I'm not set on GitHub Actions vs Travis CI vs {whatever}; just trying what's close at hand first.

The 'test' in subject refers to "does the code compile" testing, not "does the extension actually work" testing in #22.

I treat this first comment as wiki page, updating periodically so pertinent info is always at top.

Current Status

Appveyor: builds are working - https://ci.appveyor.com/project/maphew/svg-explorer-extension/history - but I don't know what do with them yet, other than verify that new commits don't break the compile

GitHub Actions: not ready for Windows + Qt. Qt must be installed manually and that is not all straightforward.

TravisCI: not tried

Fman Build System: not tried (https://build-system.fman.io/)

[maphew]

See [Actions] tab and actions branch for the meagre progress on so far. I haven't found the right Windows yaml path syntax.

Progress has been made. Key things:

Use run: | instead of just run: {my cmd string}. Each line after pipe is written to a .cmd file, and then cmd.exe is run against that script with "call "{0}"". (I'm unsure what happens with the inside/outside quotes. Experience tells me subtle bugs lie therein. Proceed with attention to detail.)

Use foreslash instead of backslash, and double quotes instead of single:

pushd "C:/Program Files (x86)/Microsoft Visual Studio"
echo %cd%
:: Uncomment to find all bats in this tree
rem dir /s/b *.bat

and yes, standard comment markers rem and :: work. (My convention is rem is for disabled code and :: is for documentation.)

For safer/more reliable path handling change dirs before the command. This:

pushd "%temp%"
type winsdk-install.log

instead of:

type "%temp%/winsdk-install.log"

Build are slow, expect ~5min, and I haven't tried to compile anything yet.

[maphew]

Build command from QtCreator's "compile output" window

"C:\Qt\5.12.3\msvc2017_64\bin\qmake.exe" D:\code-maphew\svg-explorer-extension\SVGThumbnailExtension\SVGThumbnailExtension.pro -spec win32-msvc "CONFIG+=debug" "CONFIG+=qml_debug"
11:49:16: The process "C:\Qt\5.12.3\msvc2017_64\bin\qmake.exe" exited normally.
11:49:16: Starting: "C:\Qt\Tools\QtCreator\bin\jom.exe" -f D:/code-maphew/svg-explorer-extension/build-SVGThumbnailExtension-Desktop_Qt_5_12_3_MSVC2017_64bit-Debug/Makefile qmake_all

[maphew]

Feature request: Pre-installed Qt on Windows

travis: initial Windows support with non-interactive Qt installer - might be able to use their command lines:

curl -vLo qt-unified-windows-x86-online.exe http://download.qt.io/official_releases/online_installers/qt-unified-windows-x86-online.exe
qt-unified-windows-x86-online.exe --verbose --script tools/qt-installer-windows.qs

(would need qt-installer-windows.qs too)

Or maybe Test Qt Projects with Travis-CI (Windows/OSX/Linux)

[maphew]

Finally got the right incantation to install Qt headless (2e0bff94 - wait 2 instead 1 second for button push). Bloody stupid that Qt doesn't have a blessed headless install recipe. A million thanks to @benlau!

Unfortunately there's still a problem:

[181859] Created warning message box "installationErrorWithRetry": "Installer Error", "Error during installation process (qt.tools.vcredist_64):\nExecution failed (Unexpected exit code: 1603): \"C:\\Qt\\vcredist\\vcredist_sp1_x64.exe /norestart /q\""

Hopefully we can sidestep this by choco installing the vc restributable ahead of Qt installer. I'm losing my patience with this though. It's been 3 days of banging my head on the wall, in the dark.

[maphew]

A CI log error indicates there's a dialog PerformInstallationPageCallback in qt-installer-windows.qs which isn't accounted for:

[27419] Step: QInstaller::TargetDirectoryPage(0x1b56358, "TargetDirectoryPage")
[27809] Step: QInstaller::ComponentSelectionPage(0x479e540, "ComponentSelectionPage")
[27876] Step: QInstaller::LicenseAgreementPage(0x4819cf8, "LicenseAgreementPage")
[27892] Step: QInstaller::StartMenuDirectoryPage(0x1b63be0, "StartMenuDirectoryPage")
[27986] Tmp and install directories are on the same volume. Volume mount point: "C:\\" Free space available: "18.30 GB"
[27986] Installation space required: "798.83 MB" Temporary space required: "416.38 MB" Local repository size: "0.00 bytes"
[27989] Step: QInstaller::ReadyForInstallationPage(0x1b636a0, "ReadyForInstallationPage")
[27997] Control script callback "PerformInstallationPageCallback" does not exist.
[28027] backup  operation: Mkdir
[28027]     - arguments: C:/Qt
[28028] Done
[28028] perform  operation: Mkdir
[28028]     - arguments: C:/Qt
[28028] Done

-- https://github.com/maphew/svg-explorer-extension/commit/ebb15e4825013dd43668114f08b1b524a691bf6e/checks#step:3:4722

I doubt it's related to the vc redist error.

[maphew]

This SO question indicates we might be able to slap [ignore] and keep going. I dunno how tho https://stackoverflow.com/questions/21075705/qt-sdk-installation-errors-on-windows-7

[maphew]

It only took one hour for me to get Appveyor working, so +1 for Appveyor, -1 for GH Actions. (Though to be fair, I took the learning from troubleshooting Actions and applied it to Appveyor.)

https://ci.appveyor.com/project/maphew/svg-explorer-extension/history

Magic build incantation:

call %VC_DIR% %VC_VARSALL% || exit /B 1

set PATH=C:\Qt\5.12.3\msvc2017_64\bin;C:\Qt\Tools\QtCreator\bin;C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.12.25827\bin\HostX64\x64;%PATH%
set QMakeSpec=win32-msvc

pushd "C:\projects\svg-explorer-extension\SVGThumbnailExtension"
qmake.exe SVGThumbnailExtension.pro "CONFIG+=debug" "CONFIG+=qml_debug"

pushd ../build-SVGThumbnailExtension-Desktop_Qt_5_12_3_MSVC2017_64bit-Debug
jom.exe -f Makefile qmake_all

with help from:

"can't find cl error" - I had a similar case, which was solved by adding the path to cl.exe to the path environment variable, call %VC_DIR% %VC_VARSALL% (ref)

When you are building in clean command line, you should do vcvarsXXX.bat call yourself before 'qmake' call. (ref)

Followed by a round of pushd C:\Program Files (x86)\Microsoft Visual Studio\2017 && dir /s/b in the appveyor script to find the actual exe.

Not a direct solution to your problem(s), but I have setup my own ci scripts for appveyor for dynamic and static builds over here: github.com/Skycoder42/QtModules/tree/master/ci/win and github.com/Skycoder42/QtModules/blob/master/qtcreator_wizards/… - may help you to see how it's done. – Felix May 21 '18 at 14:17 (ref)

[maphew]

closed with successful implementation of #27

[GitMensch]

I suggest to reopen this and revisit at least the Actions. Using msvc-dev-cmd we have it directly setup. Using install-qt we can easily use multiple and/or different versions to build against, (since qt5 aka 5.2.1) including most current version of QT (as it uses the official binary QT download repository which is also used by the offline installer).

This way we could use Appveyor possibly for mingw and to provide the inno-setup while Actions could be used for faster tests (Appveyor is often much slower) maybe built-only and additional tools.

[maphew]

I whole-heartedly agree with opening sentence, "Installing Qt on Github Actions workflows manually is the worst." for the install-qt description. If this packaged action fixes that experience I'm all for it. In the testing I was doing GH Actions was noticeably slower than Appveyor. That may well be because of my approach of course; I'm prepared to be wrong!

I will delay trying anything new here for a bit; I promised to stop the code churn until #7 is complete, and @tibold may have opinions on how this area should or shouldn't work.

Can you expand on how you see using both Appveyor and Actions as complementary? e.g. what makes it worth the overhead of managing more than one CI system? (personally I don't find speed alone to be persuasive.)

[tibold]

I need to get my dev environment rolling before I can get on the CI pipeline. If GitHub Actions can work that would be the best. I have experience with Atlassian Bamboo (don't really want to use it again :D) and YAML based Azure DevOps.

[tibold]

Took a quick look at what AppVeyor offers. It looks like a rather promising choice, and since that's working already, I think we can keep using it.

[maphew]

Appveyor is tied to the developer account. I think all that's needed is to visit https://github.com/marketplace/appveyor and turn it on for @tibold, and then change the auth token in appveyor.yml. I'm not sure where you find the token though.

[GitMensch]

The API key can be found (after login) at https://ci.appveyor.com/api-keys. The GH Actions are tighter bound to the repository but it looks like they currently don't work well with forks good (with Appveyor it is just a fork + inclusion in own Appveyor and it runs as it does on the main repo before the PR (with the exception of push to GH, which is normally not wanted in any case).

[tibold]

The AppVeyor builds work now and can produce installers.

For tests, I'll open a separate issue.