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]

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.