CI: Disable linux 32 bits travis build

[bcardiff]

linux 32 bits build in travis are failing a lot due to OOM (Out of memory) but on CircleCI they are running fine/better.

This disabled that portion in travis, keeping linux64 builds and notifications to IRC/Slack

[straight-shoota]

I fear this is only treating the symptoms.

We know from #6961 that even 64-bit linux specs tend to run OOM on travis, even if there should be plenty memory available.
Has someone actually looked into that?

[RX14]

travis and circle's 32bit builds should fail as often as each other's. The only difference should be on 64bit builds.

[bcardiff]

@RX14 I don't follow why the difference should be on 64bit builds. I've usually seen OOM in 32 bits in travis mostly.

[RX14]

@bcardiff the difference is because the travis and circleci build VMs have different amounts of memory. In 32bit that shouldn't matter because you can only address 4gb of it. But it seems to OOM more on 32bit travis somehow. I don't understand it.

[straight-shoota]

That's actually similar on 64-bits, only far less frequent. Travis on 64 bit occassionally runs OOM, on circle we only know one instance where this happend.

[bcardiff]

What do we want to do regarding this PR? should we keep 32 bits only in circle or leave things as they are right now for the time being?

[straight-shoota]

Yes, let's merge this for now. We can always reconsider 32-bit on travis after #6961 is solved.

[straight-shoota]

Now 32-bit on circleci fails pretty regularly as well (about every third build).

[asterite]

Alternatively I was thinking of writing a bash script or any script that, in 32-bit ci, would run specs split by directory. So one run for all spec/std/*, one run for all spec/std/json/**, one run for all spec/compiler/semantic/**, something like that. The compiler specs leak memory and on 32 bits it's more noticeable. I think doing some hack/fix on CI 32 bits is a better way to go rather than disabling it (by I'm a newb writing bash scripts).