Switch travis-ci to use the trusty beta

[bhundven]

Issues with SSL and other weirdness are creeping into our build.
Switch to the new trusty beta on travis-ci.

Signed-off-by: Bryan Hundven bryanhundven@gmail.com

[bhundven]

:sigh:

The job exceeded the maximum time limit for jobs, and has been terminated.

[stilor]

And one more:

python is missing or unusable

[bhundven]

Good catch.

The bigger problem is that bringing up the new trusty host takes too long, and our build takes too long on that infrastructure.

I'll talk with the travis-ci guys again, and see what we can do now, but in my opinion we should probably look for other ways to run ci builds.

[stilor]

As I said, I have a small Python script that schedules CI builds in my workstation's down time (i.e. overnight) - it pulls GIT master repo and if there have been new revisions, starts running the samples one by one. It also pulls the repo after each sample, so it may build sample X with revision A, then sample Y with revisions A+B, then Z with A+B, then re-build X with A+B. The goal for the script was to achieve a broader testing than Travis CI does - eventually testing all samples. But with the current commit activity so far, the script managed to keep up, testing every revision separately 😁. I think it may be a viable approach: we won't know immediately if a given PR breaks anything, but we'll know soon enough (i.e. within 2-3 days) and if the commit author is not responding, back out the change. After all, being able to roll back is one of the purposes of a VCS, is it not?

[stilor]

So, Bryan, what are we going to do with all the PRs? I suggest in absense of Travis or any other pre-commit, we merge PRs based on review - I'll provide post-commit build testing. I can add you to the list of email recipients for the build results in my script, or I can just raise issues if a build fails after a given commit, your choice. Don't let Travis kill ct-ng.