Add AppVeyor configuration file for running MSVC tests

[pwuertz]

I was looking for a way to modify and test Pull Requests without flooding you with superfluous notifications, so I ended up enabling automated tests for my GitHub clone too. This works out of the box with TravisCI, but since there is no AppVeyor configuration file I had to set up the MSVC tests manually.

This PR is a proposal for defining the automated tests by configuration file within the repository. I set up a new .appveyor.yml for testing Qt 5.6 and Qt 5.9 on the default AppVeyor image. The only manual step in enabling tests now is to set the default configuration name to .appveyor.yml on the AppVeyor settings page.

[codecov]

Codecov Report

Merging #19 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #19   +/-   ##
=======================================
  Coverage   99.07%   99.07%           
=======================================
  Files           6        6           
  Lines         325      325           
=======================================
  Hits          322      322           
  Misses          3        3

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8da467e...12c0772. Read the comment docs.

[simonbrunel]

I initially decided to not add AppVeyor config on the repo because it's much easier to tweak the build environment without pushing useless commits, though I'm ok to add it if that simplifies working on forks.

Currently I'm testing the following setup:

• Qt 5.6 + msvc2013
• Qt 5.10 + msvc2013_64

I really want to keep MSVC 2013 (32 & 64 bit) since it will fail more easily than 2015, however we can use 5.9 LTS instead of 5.10. Not sure if we should test both MSVC 2013 & 21015, neither if we should also test latest Qt version (5.11)?

Here is the associated .yaml, exported from the dashboard and reformatted to match .travis.yml style:

image: Visual Studio 2015

init:
  - cmd: call "C:\Program Files (x86)\Microsoft Visual Studio "%VSVER%".0\VC\vcvarsall.bat" %ARCH%

environment:
  PATH: '%PATH%;%QTDIR%\bin'
  matrix:
    - QTDIR: C:\Qt\5.6\msvc2013
      VSVER: 12
      ARCH: x86
    - QTDIR: C:\Qt\5.10\msvc2013_64
      VSVER: 12
      ARCH: x64

install:
  - cmd: qmake qtpromise.pro
  - cmd: nmake

test_script:
  - cmd: nmake check

[pwuertz]

Updated the YAML file so it matches your MSVC 2013 multi-arch setup with both Qt LTS versions being tested.

I don't think it's too bad using AppVeyor/Travis mainly for testing backward compatibility and look out for problems introduced by new versions in development environments. As you said, there is the burden of manually updating the environment (either yaml or dashboard), so testing the less frequent LTS versions only should keep that stress down a bit.

The AppVeyor mappings from C:\Qt\5.X.Y to C:\Qt\5.X are nice though. Maybe one could think of a C:\Qt\latest mapping, possibly implemented by scripting it in the configuration. It's just that I really dislike cmd for anything beyond cd :).

[pwuertz]

For reference: https://stackoverflow.com/questions/11645226/choose-highest-numbered-file-batch-file

[simonbrunel]

Thanks @pwuertz

Maybe one could think of a C:\Qt\latest mapping ...

I like that concept but not sure I would like this implemented in the configuration.

Could be something interesting to ask in appveyor/ci

[pwuertz]

Asking for C:\Qt\latest in appveyor/ci#2370

[pwuertz]

Approved... wow, that was quick :D