I’m doing the GitHub/Travis-CI integration in a class with 165 students. With only one concurrent build instance, and roughly two minutes of total compute for Travis to construct everything and run the unit tests, you can see how the latency can go through the roof near deadlines.
I’ve actually come around to the idea that this isn’t a bug. It’s a feature. The unit tests and everything else (CheckStyle, ErrorProne, etc.) running on Travis-CI are exactly the same as the tests running on their local machine. But the latency on your local machine is small, whereas the latency on Travis can be much longer. As such, I tell the students that they’d better run their tests locally, and the Travis thing is for “peace of mind” to make sure they didn’t forget anything. It’s also, of course, incredibly handy for our graders.
Of note, I’ve had a few students use the “edit” buttons on GitHub and get into a confusing-for-them world of git conflicts that our TA staff have to resolve. If Travis were to respond quickly, some student might be tempted to actually use GitHub’s edit button to do all their work. With Travis responding slowly, the students are incentivized to work out whatever problem might have driven them to want to edit directly on GitHub in the first place.
We’re just using GitHub as a mechanism for checking out and committing solutions. No cross-student collaboration. No pull requests. Etc. In a class that really exercises all the Git / GitHub collaboration features, the Travis latency would be a much bigger deal and I’d be more annoyed at the one-concurrent-build restriction.