Retire the travis build which runs when commits are pushed?

[pshipton]

OpenJ9 now has some xLinux machines available for PR testing. It is still desirable to run the travis build automatically on every commit?

[DanHeidinga]

The benefit of the travis.ci build is that it runs automatically and doesn't need a committer to launch, allowing contributors to see compile failures earlier (though every PR should have been compiled prior to submitting)

The downfall with the travis.ci is that runs automatically, leading to long build queues and wasted builds. A passed travis build only indicates the x compile passed, not the tests.

What if we repurposed the travis.ci builds as a cmake testing ground? It would help everyone think about whether their change broke cmake builds or not.

@dnakamura is the cmake build ready to run in travis.ci on every PR? I don't want to train committers to ignore it if its not ready yet

[dnakamura]

@DanHeidinga I believe the last blocker is #1808

Also Re: compile times. After playing around, due to a number of factors, passing --enable-ccache to configure actually works properly on travis. This would probably drastically cut our travis build time However doing so pushes the log past the max size cutoff

[DanHeidinga]

#1808 is now merged.

@dnakamura Can you put together a PR for using travis.ci to use the cmake builds?

[dnakamura]

@DanHeidinga I have #1718 However I jsut rebased and pushed it and it appears there were breaking changes to OMR, which I have a PR open for (eclipse-omr/omr#2530). Given the close interdependency, it probably makes sense to also do a CMake build as part of the omr acceptance build

[pshipton]

Since #1718 is merged I assume this can be closed.