I've observed the existence in larger projects of "build engineers" whose sole job is to keep the project building on a regular cadence. These jobs predominantly seem to exist in C++ land.
Wasn't CI invented to solve just this problem?
Your choice: do you have the most senior engineers spend time sporadically maintaining the build system, perhaps declaring fires to try to pay off tech debt, or hire someone full time, perhaps cheaper and with better expertise, dedicated to the task instead?
CI is an orthogonal problem but that too requires maintenance - do you maintain it ad-hoc or make it the official responsibility for someone to keep maintained and flexible for the team’s needs?
I think you think I’m saying the task is keeping the build green whereas I’m saying someone has to keep the system that’s keeping the build green going and functional.
The scenario you are describing does not make sense for the commonly accepted industry definition of "build system." It would make sense if, instead, the description was "application", "product", or "system."
Many software engineers use and interpret the phrase "build system" to be something akin to make[0] or similar solution used to produce executable artifacts from source code assets.
0 - https://man.freebsd.org/cgi/man.cgi?query=make&apropos=0&sek...
I’m not sure why you’re dismissing it as something else without knowing any of the details or presuming I don’t know what I’m talking about.
>> The scenario you are describing does not make sense for the commonly accepted industry definition of "build system."
> I’m not sure why you’re dismissing it as something else without knowing any of the details or presuming I don’t know what I’m talking about.
My apologies for what I wrote giving the impression of being dismissive or implying an assessment of your knowledge. This was not my intent and instead was my expression of incredulity for a build definition requiring 20 engineers to maintain. Perhaps I misinterpreted the "cooks" responsible for build definition maintenance as being all of those 20 engineers. If so, I hope you can see how someone not involved in your project could reach this conclusion based on the quote above.
Still and all, if this[0] is the Bazel build tool you reference and its use is such that:
With that many coooks[sic], you have patches on top of patches
of your build system where everyone does the bare minimum
to meet the near term task only and it devolves into a mess
no one wants to touch over enough time.
1 - Does using Bazel reduce build definition
maintenance verses other build tools such as
Make/CMake/etc.?
2 - Does the engineering team value reproducible build
definitions as much as production and test source
artifacts?
3 - If not, why not?
To clarify the rationale behind questions #2 and #3:
Build definitions are production code, because if the system cannot be built, then it cannot be released.
Test suites are production code, because if tests fail, then the build should fail and the system cannot be released.
For me it's just about rules/discipline: Commit working code with passing unottests. Everyone is responsible for fixing stuff. You break something you'll fix it.
You wish.
These jobs exist for companies with large monorepos in other languages too and/or when you have many projects.
Plenty of stuff to handle in big companies (directory ownership, Jenkins setup, in-company dependency management and release versioning, developer experience in genernal, etc.)
There are a lot of problems, but having to carefully construct the build environment is a minor one time hassle.
Then repeated foot guns going off, no toes left, company bankrupt and banking system crashed, again