initial appveyor CI build config

[chcg]

see https://ci.appveyor.com/project/chcg/nppsnippets/build/1.4.0.3

build config for VS2015 build

[chcg]

Update to current master, see https://ci.appveyor.com/project/chcg/nppsnippets/builds/22180669

Could be extended to check:

• mingw build (see https://github.com./Governikus/AusweisApp2/blob/community/appveyor.yml#L5-L8)
• sphinx docu build (see https://github.com./bruderstein/PythonScript/blob/master/appveyor.yml#L45-L48)

[ffes]

I am reviewing this one. This project definitely needs CI!

I never have used appveyor before, so I need to dive into their yml format and their capabilities. I am tweaking the yml file.

I really see no need to use the VS2015 toolset (140_xp) any longer. It is old. I haven't used it for years. I removed the VS2015 project files from the repo. The VC-compiler has come a long way since VS2015. VS2019 is in preview already.

I am not a fan of the hardcoded version on the first line. That is why I created the version_git.* files and I want CI to use this as well.

The zip for a release should include the Template.sqlite database (see #20).

I think I have fixed the VS2015 and the zip in my local version, but I still need to test it.

There is no need to use appveyor for MinGW or the docs at the moment. The MinGW builds cannot be loaded in Notepad++ (see #21) and the docs are build by Read the Docs already (although their automatic builds seem broken at the moment).

[chcg]

@ffes

• v140_xp is mainly there because N++ itself is still using it
• the version is just used for the appveyor build name and is not used in the dll itself. It is also possible to rename the appveyor build to some own version schema, if needed.
• if mingw is a goal CI would be still of some use to verify that code changes don't contain issues breaking the compilation with mingw compiler or use features like ATL not available for mingw
• adding template.sqlite is just of interest if you are planning to use appveyor CI also for deployment to github releases. Is that the case?

[chcg]

In the meantime also github actions are available which could be used for CI builds, like e.g. https://github.com./chcg/NPP_HexEdit/runs/226069896
with config:
https://github.com./chcg/NPP_HexEdit/blob/master/.github/workflows/CI_build.yml

[ffes]

In the meantime also github actions are available which could be used for CI builds

Thanks for the reminder. I was never a big fan of those third-party CI solution. At the office we use GitLab and its integrated CI and I use that for a couple of my private projects as well. It works really nice.

I am working on a GitHub Actions CI script for this project right now. That will be committed soon, so I will close this PR.

Thanks again for your efforts. I used your HexEdit CI script as a template for mine.

[chcg]

@ffes Ok. Just let me know if you need some support for the github action. For HexEdit VM windows-2016 is used with VS2017. The support for that will end and is not mentioned any more at https://help.github.com./en/actions/reference/virtual-environments-for-github-hosted-runners. So maybe you have to switch to windows-2019 soon.

[ffes]

I noticed the "old" Windows and VS in your script, so I already updated my script to use the latest.

It took a couple of commits, but now it works as expected. For some reason they think it is a good idea not to have an option to fetch the tags. So you need to do that with a manual command.

Thanks again