Automatically build the whole system and run all of the tests in ten minutes. A build that takes longer than ten minutes will be used much less often, missing the opportunity for feedback. A shorter build doesn't give you time to drink your coffee.
Physics has reassuringly concrete natural constants. At sea level on earth, the force of gravity accelerates objects at 9.8 meters per second per second. You can count on gravity. Software has few such certainties. The ten-minute build is as close as we get in software engineering. I've observed several teams that started with an automated build-and-test process never letting the process take longer than ten minutes. If it did, someone optimized it but only until it took ten minutes again.
The ten-minute build is an ideal. What do you do on your way to that ideal? The statement of the practice gives three clues: automatically build the whole system and run all of the tests in ten minutes. If your process isn't automated, that's the first place to start. Then you may be able to build only the part of the system you have changed. Finally, you may be able to run only tests covering the part of the system at risk because of the changes you made.
Any guess about what parts of the system need to be built and what parts need to be tested introduces the risk of error. If you are wrong, you may miss unpredictable errors with all of their social and economic costs. How ever, being able to test some of the system is much better than being able to test none at all.
Automated builds are much more valuable than builds requiring manual intervention. As the general stress level rises, manual builds tend to be done less often and less well, resulting in more errors and more stress. Practices should lower stress. An automated build becomes a stress reliever at crunch time. "Did we make a mistake? Let's just build and see."