CI build via GH actions

[chcg]

• added starting point for a CI build via GH actions
• added ARM64 build

[Coises]

@chcg :

I appreciate your help, but I’m not quite comfortable with a lot of this, because I don’t fully understand it.

I can see the plausibility of adding ARM targets. I haven’t included them because I have no idea how to test them on an x64 system. The post-build step in this pull request would copy the ARM build over the x64 build in "%PROGRAMFILES%\Notepad++\plugins$(TargetName)" — surely that can’t be right? It would have to go somewhere else; my guess is that there would be no predicable place for it, so the post-build step should be omitted for ARM. Unless Visual Studio is running on ARM Windows... then the other post-build steps don’t make sense...

If you can explain to me what users of the template would need to do to create and test ARM versions, I’d be glad to include that part of this PR. Once I understand it, I can update ZipForRelease.ps1 and write it up for the help file. If I don’t understand it, I can’t document it, and I won’t be comfortable including it.

The continuous integration doesn’t seem useful to me. This is not a GitHub template, it’s a Visual Studio template. The artifacts are just zip files of the source. Unfortunately, the source code zip files from GitHub have a folder at the root which contains the source, while MSVS templates must have the key template files directly in the root of the zip. I attach zip artifacts to releases so users won’t have to unzip the source code zips and re-zip them without the extraneous folder; but anyone can do that from any point in the GitHub project history. I suppose it tests that everything compiles... sort of, but again, this isn’t compiled to a usable dll, it’s used as a Visual Studio template to create new projects. I test to see that it works — as a template, as well as checking that a project made from the template compiles and runs in Notepad++ — before I upload a change. I don’t see what this covers that I don’t have to do manually already.

I’m not sure I understand the Dependabot bit. If the point is to provide something for users, I don’t think it will work, because this is a Visual Studio template, not a GitHub template. If it’s for this repo, then the problem is that I have no idea what to do with what you’ve started, and I don’t think it does anything as submitted. I use a dozen interface files for Notepad++ (including Scintilla within Notepad++) and a single header-only file from JSON for Modern C++. If Dependabot can be configured to create a pull request automatically when a new release of one of those projects changes one of the files I use that would update the corresponding file in my template, that could be useful. I would still have to test. (For example, a recent change in Notepad++ renamed IDM_EDIT_SETREADONLY to IDM_EDIT_TOGGLEREADONLY, which I had to change in my model About box.) Again, I’m stuck at it sounds like a good idea, but until and unless I understand it, I don’t feel good about including it.

[chcg]

For ARM64 I just did a copy of the x64 version to see if the compilation is working. The postbuild steps I was not aware of. As most people are running on x86 I guess they are just cross compiling for ARM64 and have no change to test it. So I agree that for the template it should be removed.

I thought of this repo more like a starting point where someone could fork his own project from similar to https://github.com/npp-plugins/plugintemplate . But likely that is not the case and I'm not sure how to provide github CI build config as a template for your users. This PR was not mainly meant to support your workflow.

See VirtualFolders which is based on your project and a corresponding PR to build that project
FatihC/VirtualFolders#3 .

Dependabot could automatically create PRs on updates for more standardised ecosystems like nuget, python, ... and github actions like added here. Unfortunately there is no as easily usable corresponding service for C++ dependencies (see https://github.com/marketplace/actions/spdx-to-dependency-graph-action as there is no sbom generator for C++ dependencies to my knowledge )