For a long local build, add one completion cue and leave the log available. That lets you do another small task without repeatedly bringing Terminal forward just to see whether the process ended.
Define what completion means
Inspect the project’s build script. It may compile only, or it may also run type checks and tests. A cue attached to that command represents that script’s end, not checks it never performed.
For a quick success cue, use the afplay pattern. If you need to notice failures too, use separate outcomes and preserve the original exit status.
Keep the review step visible
Leave the terminal window and log intact. When the sound plays, return and check the result, warnings and generated output. Do not start deployment merely because the sound was the successful one.
A build over SSH or in hosted CI does not run its audio through your local Mac automatically. Use the platform’s intended notification channel for those jobs.
Choose useful waiting work
Prefer a short task you can stop when the build ends: read a relevant document, prepare a test case or note the next review step. Starting several unrelated builds can make an anonymous chime hard to interpret.
If an agent owns the build, its turn may continue after compilation. Agent done versus command success explains why the two events should be kept distinct.
Sources: macOS afplay -h; TapNoise cue semantics.
TapNoise