"Sorry! My bad!" is how I usually apologize when I've broken the build. It happens. But as others have said, this is an opportunity to improve your systems so that one person cannot so easily break the build for everyone else.
I would not make a formal apology in these circumstances, but if you actually feel that a more formal apology is appropriate, then your apology should do these things:
- Express regret.
- State the problem.
- Take responsibility.
- Make amends.
- Save face.
That is, "I'm sorry [EXPRESS REGRET] that I inconvenienced you [TAKE RESPONSIBILITY] by accidentally [SAVE FACE] breaking the build [STATE THE PROBLEM]. Doughnuts are on me tomorrow. [MAKE AMENDS]"
Each part is necessary in a proper apology; if you don't state the problem then it is unclear. If you don't express regret, take responsibility, and make amends, then people feel like you're insincere. The face-saving part is the most overlooked part of an apology; the face-saving part is what reminds the injured party that you are a valuable coworker who sometimes makes mistakes, and not an idiot (or a saboteur!)
Finally, some thoughts on build breaking:
I work on the C#/Visual Basic compiler team. Of course today Visual Studio is now such a massive project that it has a team of its own just to manage build infrastructure, and a huge room with its own dedicated air conditioning system. Back in the mid 1990s when I started as an intern the Visual Basic build team was one intern -- me -- and a closet full of machines. Times have changed!
Back in those days before continuous integration and strong checkin processes, teams would have a variety of penalties for breaking the build. On some teams the penalty was that if you broke the build, you had to wear a funny hat every day at work until someone else broke the build. On some teams, if you were wearing that hat you were responsible for verifying that the nightly build was correct.
That last bit sounds maybe cruel, but it actually served a valuable purpose. Since almost everyone broke the build at one time or another, eventually the entire team would learn the processes for verifying the nightly build.