GIthub actions docker containers (for windows build)

[Paul Buxton]

So the change to CMake is in MXE, in fact I don't think we install cmake as
a package in the container other than as part of MXE.

They updated it in October, and the version we are currently using in
Subsurface is from June, so I think I will have to just take the head of
MXE and work through the issues. Not a problem, it just would have been
easier to be able to make the changes incrementally to fix problems one at
a time :-)




On Tue, 26 May 2020, 16:28 Dirk Hohndel, <dirk at hohndel.org> wrote:

> So the logic of why we were building the container from our source tree
> was in order to ensure that you can easily reproduce the outcome.
>
> There is a small issue with that as Ubuntu might update some versions, but
> I'd be surprised if we saw a jump from 3.10 to 3.15. cmake is provided by
> the host OS (so Ubuntu in this case).
> Are you starting from the same base distribution?
>
> The MXE version is fixed as a specific SHA. And as I grep through the
> sources to refresh my memory where that's done I notice that the SHA
> doesn't appear to be in the source tree. How weird.
> I believe the last one that I used (based on the remnants of local builds)
> was 9f6b9c6f - but I need to dig some more to figure out why this isn't in
> the sources...
>
> /D
>
> On May 26, 2020, at 12:41 AM, Paul Buxton <paulbuxton.mail at googlemail.com>
> wrote:
>
> Hmm,
>
> Started to look at updating the container. But I am hitting some issues
> trying to run with a locally built version of the official container.
> Do you know what version of MXE the container on github was generated from
> in case I need to chop to see where the failure comes from?
>
> My suspicion is that the problems are related to the version of CMake
> being used. MXE now seems to pull in 3.15 and the official container is
> using 3.10
>
> On Fri, May 22, 2020 at 4:29 PM Dirk Hohndel <dirk at hohndel.org> wrote:
>
>>
>>
>> > 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20200526/5a54342d/attachment-0001.html>