The best approach to continuous integration is to perform the whole test suite on every change being pushed to the central repository. Even if one programmer pushes a series of multiple commits in a single branch, it often makes sense to test each change separately. If you decide to test only the latest change set in a single repository push, then it will be harder to find sources of possible regression problems that were introduced somewhere in the middle.
Of course, many DVCS, such as Git or Mercurial, allow you to limit time spent on searching regression sources by providing commands to bisect the history of changes, but in practice, it is much more convenient to do that automatically as part of your continuous integration process.
There is an issue of projects that have very long running test suites that may require tens of minutes or even hours to complete. One server may not be enough to perform all the builds on every commit made in the given time frame. This will make waiting for results even longer. In fact, long running tests are a problem on their own that will be described later in the Problem 2 – Too long building time section.
For now, you should know that you should always strive to test every commit pushed to the repository. If you have no power to do that on a single server, then set up the whole building cluster. If you are using a paid service, then pay for a higher pricing plan with more parallel builds. Hardware is cheap. Your developers' time is not. Eventually, you will save more money by having faster parallel builds and a more expensive CI setup than you would save on skipping tests for selected changes.