There are a few reasons for this:

The setting for auto-cancelling multiple (duplicate) test runs for consecutive commits on one branch had been turned off. I've turned it back on, and this should de-dupe test runs from the same PRs.
Now that we're sharding unit tests and integration tests, we're building twice, once on each shard. This will be fixed with Clean up unit tests and move all integration tests to integration/ #9404 and Optimizations to speed up Travis PR builds #9626
We're unnecessarily doing a dist for the integration_tests shard on PRs. We only need to do so on master. This will be fixed with Don't do a dist in the integration_tests shard for PRs #9530
Prior to sharding, a run with a presubmit error would fail early prior to the full build. Now, the unrelated shards will still be run. This is a case of a shorter wait in the average case, but a potentially longer wait in the worst case. I'm investigating a way to cancel all jobs for a run if one job fails. (Edit: It would actually be preferable not to do this, since it'd be beneficial to see results from pre_build_tests even if integration_tests were to fail, for example)

Of course, if it's feasible, adding more VMs would alleviate the worst case and greatly improve the best case.

Tasks queued up in Travis #9500

Description