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.
