Nice find. However, given that it is not documented, it might go away or break any time and we shouldn't expect travis to provide any support for it.

@MarcoFalke I can add allow_failures so the builds won't fail if it doesn't work. (altough that means manually checking if PPC passed)

altough that means manually checking if PPC passed

As if anyone would do that

Also according to #6466 we were looking for a be build, not le. Travis is already pretty slow these days and adding another build (which is mostly redundant to the other le builds) does not help in that regard.

I agree that if it was big endian it would've been nicer.
But I do think it's valuable to have CI for every platform we're aiming to support, as it's very easy to break support with one the second we use non C++ stuff (i.e. libc, asm etc.)

Concept ACK

Very nice find! :)

we use non C++ stuff (i.e. libc, asm etc.)

We use the Ubuntu Bionic libc on all builds, no? So at least that shouldn't matter.

You mean when distributing binaries, right?

The ci system is running (at least on travis) in ubuntu:bionic docker containers.

Also according to #6466 we were looking for a be build, not le. Travis is already pretty slow these days and adding another build (which is mostly redundant to the other le builds) does not help in that regard.

I tend to agree. Adding a big-endian build / test (irrespective of platform) would be great. PPC LE is worth testing on intermittently, but don't think it needs to run for every PR and commit (I made a similar argument for RISC-V in #17089).

Don't get me wrong, I appreciate the work you put in here and I am going to steal it for my projects (e.g. intermittent tests as suggested by @laanwj), but it might not be the best fit for the Bitcoin Core repo.

I guess I agree, about the times.
for the same reason RISC-V didn't get merged, this i guess shouldn't get merged either.

But this just makes me wonder if travis is hurting us in the long run.
Giving up on testcases because "travis is already too slow" is a bad sign (not talking specifically about this PR, for that sense it can be even running valgrind).

Anyway, that's unrelated to this PR(i'll see if I have time to look into serious infrastructure (I think this is already a serious enough project to have serious infra)).

It is possible to send them money to speed it up for us (#16148 (comment)). However, that will also slow it down for "local" travis testing in forks.

But this just makes me wonder if travis is hurting us in the long run.

Well a bad craftsman blames his tools. Yes, travis is problematic sometimes, but also our test suite is very much on the heavy side. Both the build and tests somehow take very long compared to other projects.

If it means thorough testing that's good, of course. But maybe it'd be nice to have a subset of fast tests that we can run as often on as many platforms as possible. Maybe foregoing for ex. depends builds.

But this just makes me wonder if travis is hurting us in the long run.

Well a bad craftsman blames his tools. Yes, travis is problematic sometimes, but also our test suite is very much on the heavy side. Both the build and tests somehow take very long compared to other projects.

If it means thorough testing that's good, of course. But maybe it'd be nice to have a subset of fast tests that we can run as often on as many platforms as possible. Maybe foregoing for ex. depends builds.

I still somewhat blame Travis (i.e. Using a robust Jenkins like server everything is parallel in it's own spots/machine so new jobs don't make the tests longer).

But you're right, maybe a good goal is to start figuring out what takes so much time and how can we fix that.
Is it compile time or test time? can we change includes and/or libraries to make compile time faster? can we change test framework(or the way we test) to make tests run faster? Should we introduce ccache into the CI? (These are all open questions in my mind, I never looked into them and the answer might be "no" to all of them)

Is it compile time or test time?

Without cache it is compile time (due to boost and serialize.h).
With cache it is install time (apt-get) and a bit of the functional tests.

can we change includes and/or libraries to make compile time faster?

Yes, see e.g. #17401 and #17307.

can we change test framework(or the way we test) to make tests run faster?

Yes, see e.g. #15858 or #16613.

Should we introduce ccache into the CI?

Yes (we already do for normal compiles), but it is not picked up by depends: #17103

https://blog.travis-ci.com/2019-11-12-multi-cpu-architecture-ibm-power-ibm-z#what-you-can-expect-from-this-alpha-release

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #17591 (ci: Add big endian platform - s390x by elichai)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

@MarcoFalke Am I dreaming or are they also supporting s390x which is BE?
I'll test with a small travis to check that it's actually BE and then PR it :)

EDIT: Definitely Big Endian :)

I don't see a good reason to leave this open.