Travis CI timeouts for MacPorts builds

[Ryan Schmidt]

On Sep 7, 2020, at 13:25, Ralph Seichter wrote:

> * Mojca Miklavec:
> 
>> It tries to install dependencies as binaries, provided the binaries
>> are available.
> 
> Tries being the operative word here. ;-)

What are you trying to say? It uses binary archives if available, and they should be available. Private archives are available to the CI machines provided their IP address has been whitelisted in our CDN config. I just verified that the Travis IP addresses haven't changed.

It is possible that for some reason it is unable to access the private archives. Or it's possible that downloading the private archives is taking too long. (They're hosted on a server with limited bandwidth. We have a CDN in front, but if the file is not on the CDN yet, it needs to come from the slow server.) We would need to see logs to know for sure what's happening.


>> We should figure out:
>> - which dependencies time out
>> - why they are not installed from (the private) binary package repository
> 
> I'm guessing that "we" means the devs who maintain the build config. If
> I can assist, let me know, but I don't think it likely at this point.

I deal with the buildbot infrastructure but am less familiar with how we've set things up at Travis and Azure. We would need to see logs of the installation of the dependencies to know why they're taking so long, but I don't see any such logs, and don't know where or how that's happening or not happening.


> At a glance, I'd expect a glib2 build from source to be quite a drag.
> The various xorg-* ports might also take some time. I don't see why the
> latter would be required,

Both glib2 and most of the xorg ports, as far as I recall, are distributable, meaning binary archives should be publicly available.

> given that the build apparently did not use
> the +emacs variant?

The build infrastructure, both buildbot and Travis and Azure, builds for default variants only.


>> Generally we mostly ignore Travis results, so there's no real reason
>> to worry in your case.
> 
> If you ignore Travis results, why run Travis CI in the first place? I
> suggest to either fix the underlying issue or remove Travis builds. That
> would at least free up some server resources, for the benefit of other
> projects which actually rely on their Travis builds.

We don't "ignore Travis results". However if a pull request comes in that shows a failure from Travis due to the 50 minute timeout, and successful builds from Azure, we'll accept the PR. I already said that we don't need two different systems testing the same OS/Xcode combination and if we're currently doing that then we should get rid of the brittle Travis builds for those OS/Xcode combinations and use just the more reliable Azure ones.