Travis CI timeouts for MacPorts builds

[Mojca Miklavec]

On Tue, 8 Sep 2020 at 19:11, Ralph Seichter wrote:
>
> * Ryan Schmidt:
>
> >> Tries being the operative word here. ;-)
> >
> > What are you trying to say?
>
> Did I step on somebody's toes?

I'm not aware why you would step on anyone's toes, but I also didn't
understand what you tried to say in that sentence.

> I am saying that the build that concerns
> me timed out setting up the dependencies. That, from my understanding,
> means the dependencies were either unavailable in binary form, or that
> the attempt to access said binary form failed. Hence my comment above,
> in an attempt to make light of the situation, as the smiley indicates.
>
> > 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.
>
> That makes tackling the underlying issue difficult, of course.

You can in fact look at the equivalent builds from Azure, for example here:
https://dev.azure.com/macports/macports-ports/_build/results?buildId=9200&view=logs&j=dde54236-b8c5-5879-af99-818e7b59912f&t=204c7e84-6a60-5987-1292-f9e129aab6e1

At the bottom you have a pastebin link with the build log of the port itself.
However the logs from building dependencies are apparently missing. I
thought those were available as well.
I'm not 100% sure, but maybe we deliberately removed those at some
point because it was consuming significant resources and it was deemed
nearly useless. (I'm not saying that's true in your case.)

> > We don't "ignore Travis results".
>
> Mojca Miklavec wrote (quote) "Generally we mostly ignore Travis results,
> so there's no real reason to worry in your case.", which led me to
> believe that you generally mostly ignore Travis results. How silly of
> me. :-)

Just to clarify my oversimplification.

We don't literally ignore the results.

If the Travis builds succeed ... we usually ignore the details :) :) :)

If the Travis build fails, we would usually look into the reason for
the failure, however:

(1) In nearly all the cases (not all though!!!) the reason for the
failure is either timeout or some network or timing issue. If that
happens, we would "ignore" the fact that Travis build failed. What
this mostly means is that users should not worry that their PR won't
be accepted just because Travis decided to put a red cross to the CI
job. In some cases the port would be manually checked by someone else
to ensure that it builds. We could have payed a bit more attention to
the individual builds to see if there is some flaw and we could have
forced the dependencies to build faster.

(2) In some other cases there would be a real build failure, but again
this most often means that it would fail everywhere, so we would see a
failure on Azure as well.

(3) There's another large class of cases where the software is only
supported on, say, 10.14 and newer. In those cases the Azure build
would succeed (just because it only uses the newer OS versions) and
the Travis build would fail (as it tries to build on older builders).
But again, if someone is porting software that upstream doesn't bother
supporting on older OSes, we won't generally block the PR just because
the older macOS versions are no longer compatible.

There certainly are cases where the results are useful. It's just not
as often as we wish it would be.

Mojca