Normally a buildserver is not interested in the history of the repository. On the other hand it needs some context, to show what was changed. For me the best option is a shallow clone, that can be also used to incrementally pull. Because a pull with not much changes will still be faster than a full shallow clone.

The build should be as simple as possible. e.g. make is better than make clean generate build test release

The buildfile should work for all parties. Its a wide range from developers to buildservers. If all use the same, errors are found earlier on and the project makes sure that all important steps are in git.

My first choice is to not depend on preinstalled tools but put everything into the workspace and make it self contained. Another option is using docker images, but this has another set of drawbacks.

Every gap between different buildsystems makes the whole image less correct / efficient. E.g. recursive make considered harmful.

Put all build artifacts to a common folder structure that is outside of the source folders. This makes your gitignore files very straight forward + you do not even need a clean buildstep, because you just can delete one folder.

Make your buildlogs meaningful. Reduce warnings, remove debug output.

The results of a build should be as compact as possible. Saving everything without a requirement is not fast and not cheap.

Do not hardcode -j16 or something into your build. This should be possible for the buildservers to decide. They know best what resources they have and how many parallel jobs they have to serve.

A viable compromis might be to do some edges of the build in a dirty way, if it really brings speed. E.g. create dockerimages with a snapshot, so that not all work has to be done from scratch.