Hello,
On Tue, Sep 08, 2020 at 06:39:41PM +0200, Mojca Miklavec wrote:
On Mon, 7 Sep 2020 at 20:25, Ralph Seichter wrote:
If you ignore Travis results, why run Travis CI in the first place?
Travis was the first CI that we supported for pull requests.
@l2dy wrote the initial support as a GSOC project which included
writing tons of workarounds for Travis limitations.
He redirected output to pastebin in order to be able to even show it
(most of our output exceeds the Travis limit for how long the log can
be), he had to inject bogus writes to prevent Travis from thinking
that the job was stuck, he implemented a lot of tricks to ensure that
the bootstrapping phase was as fast as possible, ... but we could not
change the time limit itself.
After a while Azure came around with 6 hours of timeout which was a
lot more useful, and the same solution was ported from Travis to
Azure. I forgot why we never switched from Azure to GitHub Actions.
Done in commit db7b40d8691e1fcd8b6be5e3c2a2a00a7ce0bdf4. We should
remove Travis CI and Azure Pipelines soon.
GitHub Actions' IPs should be added to the pastebin allowlist. Logs are
uploaded as artifacts, but they are zipped[1], so uploading to
paste.macports.org is still preferred.
[1]:
https://github.com/actions/upload-artifact/blob/v2/README.md#zipped-artifact-downloads
It's not that Travis is completely ignored. There are some useful
cases, like this one for example:
https://travis-ci.org/github/macports/macports-ports/builds/724968783
(I checked a random failed build from the recent PRs.)
You can see that the build passed on 10.14, but failed on 10.11 up to
10.13. It failed quickly with
"Xcode 9.0 or greater is needed to build carthage; only found
version 7.3.1."
which is something that the portfile should have declared and it
should have at least failed in pre-fetch phase already (ideally we
would need a declarative syntax for this).
This case is useful. Now, we do have Azure build for 10.13, so this
one is overlapping (and we should probably remove that one), but
there's no builder for 10.11 and 10.12 on Azure.
In reality most of the Travis build failures fall into two categories:
- timeout (most of the time)
- network or timing issues (sources could not be fetched with "server
not found", or the clocks didn't match, and MacPorts refuses to run if
file appear to be "from the future")
As far as I know there were attempts to address both of these. Timeout
will always be the case when a single PR touches many ports, or where
ports are simply time-consuming to build (no chance for Qt, ...) There
might be room for improvement as far as build time of dependencies is
concerned though.
On Tue, 8 Sep 2020 at 18:28, Ryan Schmidt wrote:
On Sep 7, 2020, at 11:24, Ruben Di Battista wrote:
> Would à Linux machine with some virtualization method (libvirt?) be
acceptable as CI runner?
I can't see how, since we're trying to verify builds of ports, and there is no
general expectation that port builds would work on non-Mac operating systems.
We are not talking about running the builds on Linux, but running the
virtual machines on Linux, and if wasn't for the legal reasons, this
would be a perfectly viable solution (provided you get all the VMs
working, to start with). But if you get it working on linux for
testing purposes, a very similar recipe might work on macOS.
Mojca
