Add mingw-w64 (Windows) CI build

[eht16]

Please welcome a new way to build Geany and Geany-Plugins for Windows in the CI.

What's in here:

• the workflow job to checkout Geany-Plugins, Geany and Infrastructure repositories
• use the supporting scripts in https://github.com/geany/infrastructure/tree/add_ci_builders/builders to
  • build a Docker image with a full MSYS2 installation (or pull the image from the Geany Docker registry if available)
  • use this Docker image to:
    • build Geany and create a release-like installer for it as build dependency for the G-P build (or use cache if available)
    • install Geany from the previously built Geany installer
    • build Geany-Plugins and create and test an installer
    • store the Geany and Geany-Plugins installer as artifact on Github

Mostly all of the work is done in the builder scripts on https://github.com/geany/infrastructure/tree/add_ci_builders/builders. Unfortunately, it grew more than than expected in terms of amount of code.

I tried to document at least the basics so anyone else than me will be available to get an idea what is happening. Let me know if it worked :).

There is a difference to the Linux CI build which more or less aims at using a rather old setup to ensure backwards compability. The Mingw-w64 build instead always pulls the latest available packages from the MSYS2 repositories. I think this is OK as this is also what we do on releases and since we bundle all dependencies into the installer (for release builds as well as for CI builds), the result should be consistent.

In preparation for the upcoming GTK version requirement change, I updated the Linux build to Ubuntu 20.04 LTS (which has a recent enough GTK3 version).

Best of all: during the CI build Windows installers are created for Geany and Geany-Plugins and they are stored as artifacts and can be downloaded later on (up to 30 days).

Remarks:

• [ ] this branch needs a bit more testing with this PR
• [x] after this has been merged, I will start adding the corresponding mingw-w64 CI job for Geany (which is relatively easy after this monster)
• [ ] we need to merge the PR https://github.com/geany/infrastructure/pull/7 first

For now, the necessary Docker image was uploaded to https://github.com/geany/infrastructure/pkgs/container/geany-mingw64-ci by me manually. Basically we could push the image also from the CI job but I'm hesitating to allow this because of the risks it offers to malicious users. Maybe I'll add a separate job in the infrastructure repository later to build and push the image there and restrict this job to admins

[eht16]

@elextr @techee @b4n @kugel- review is welcome and don't be scared even there is much Windows and mingw in the title and description, the main part is just bash code to be executed on Linux and some Github Actions job definition :).

[elextr]

don't be scared even there is much Windows and mingw in the title

and github actions and docker and ... @elextr cautiously pokes PR, leaps on chair screaming when the word "Windows" appeared :grin:

I tried to document at least the basics so anyone else than me will be available to get an idea what is happening. Let me know if it worked :).

Only a vague general outline, but thats more likely my lack of any detailed knowledge of mingw, docker, github actions (all the technologies used here :-) than your docs.

So I can say LGBI, but I doubt that inspection actually added any value ;-)

Probably best to get GP CI working again so this can be merged and tested.

[elextr]

This needs to be merged, its CI, it needs to run as CI for all plugins and we won't ever know if it works unless its merged so it applies to all plugins and their PRs. It can always be reverted (or preferably fixed) if it breaks something so don't be timid. But AFAIK we will never know until its merged and all (or at least those without conflicts) PRs are triggered to re-run.

[eht16]

I fully agree. I just cleaned up the commit history and removed temporary test settings. Though we need to merge https://github.com/geany/geany/pull/3315 before.

There seems to be a new issue with the Linux build at "make distcheck" which might be related to the updated Ubuntu version (18.04 to 20.04), though I still have not yet investigated what's the root cause.

[elextr]

Failure is /bin/bash: valac: command not found, did it get installed?

[elextr]

Multiterm would appear to be GTK2 only https://github.com/geany/geany-plugins/blob/a8fd23125049d0a0ae8655e2bf95d3f447b3dacd/build/multiterm.m4#L6 so should not be being CIed.

[Edit: If configure is not going to disable GTK2 plugins correctly, maybe they should be removed from the build? ]

[eht16]

Multiterm would appear to be GTK2 only

https://github.com/geany/geany-plugins/blob/a8fd23125049d0a0ae8655e2bf95d3f447b3dacd/build/multiterm.m4#L6 so should not be being CIed.

Yes, but even if it is disabled (by ./configure itself and with --disable-plugin-multiterm explicitly), make distcheck wants to call valac anyway.

I guess this is some autotools magic which I do not understand.

We probably should finally remove old, unmaintained plugins from G-P.

[elextr]

We probably should finally remove old, unmaintained plugins from G-P.

Yes, even if they are deleted, they are still in the repository, not lost. If "somebody" wanted to resurrect a plugin they only need to checkout the 1.38 tag to get the source.

[eht16]

Incorporated the changes from https://github.com/geany/geany/pull/3465 and builds are fine now.

I would like to merge this finally in a few days if there are no objections.