GIthub actions docker containers (for windows build)

[Dirk Hohndel]

> On May 22, 2020, at 8:11 AM, Paul Buxton via subsurface <subsurface at subsurface-divelog.org> wrote:
> 
> So before I make any pull requests that might break the builds, I just want to check I understand the way that the github build for windows operates now.
> The mxe-dockerimage-stage1.yml detects changes to scripts/docker/mxe-build-container and the mxe workflows. Which will trigger a build of the container.
> The container will pick up the version in this yaml file. When building that has finished it will trigger the stage 2 build which is based on the container created in stage 1.

Correct. And frankly, that whole thing is bogus. If you'd rather just create and test a container locally, go ahead and test it locally and once it works let me know and we can update the container that we use to build the Windows binaries.

The idea behind doing this on GitHub was solid. But the implementation is painfully slow and fragile. And worse, the resulting docker containers contain all intermediate layers - which generally is what you want, but which here creates a resulting container that is more than twice as big as it needs to be. Which strains GitHub's resources and slows down our tests. So for the other two containers (Android and AppImage) I have started to go back to building them locally. I still keep the Dockerfile in the source updated so that it matches what I build, but... yeah.

> So If I make changes to the windows containers then I need to update the VERSION field in the stage1 yaml file to avoid inadvertently trashing the existing subsurface/mxe-build-container:1.0 
> 
> Is this correct?

That's correct.

> Also the scripts in scripts/windows-container are effectively legacy, and presumably kept for people building locally?

Also correct.

Let me know if you have more questions and need pointers. I'm 8 hours behind you, so your afternoons / evenings are better for me :)

/D