More and more, I feel that the goal of a build is very simple. The goal is to provide a convincing illusion of done.
Some people might disagree with my wording. Illusion? Isn't that something we should avoid? But, the fact of the matter is that we are never done. There is always one more test that we can dream up and run. When builds pass, software goes into production. Sometimes we find bugs. We correct them. Sometimes new features are needed. It's all work. We are never done.
For an area of code, all we know is how long it has been free of defects. Builds should help us radically shorten the amount of time it takes to find them. In fact, in a high performance team, very few bugs should escape into production. And, if they do, they should be found and repaired quickly.
So, that is what a build looks like from a technical point of view. But, there is another way of looking at a build. When developers check in code, they need to get some sense of completion, and it's better when they get it quickly. We could gloss this over and say that it is not necessary, but I think it really is. Development is an attention-focused activity, and for me at least, a sense of closure is important for that focus and important for morale. All of that evaporates with awareness of the long pipeline toward the eventual discovery of a fault. At a certain point, I want to be able to say, "based upon what we know, we can consider this to be correct now", and I want that to happen as early as possible.
How can you get to that sense as the number of tests grow in a system? I don't know, but subjectively, what I wish for is quality at a level where about 99% of errors are found with in minutes of commission. I want to be able to call that done. The remaining 1%, well, it may take a while to discover those, but as a developer, I don't want to have to have to think about those right away. Spill them back to me in bug reports. Pipe-dream? Perhaps. But I think there's value in a convincing illusion of done.