Makes a lot of sense, and if you thus are able to store the current git-hash (or svn-revision) and all the build settings for your report, you'd be fully informed. But the sink you put into shouldn't be part of the build-system core but a plugin, because most companies will have a custom solution for that.On 5 October 2016 at 10:43, Dominique Devienne <ddevienne@gmail.com> wrote:
[...] I don't think we need (or should) store the state of the build in any form, i.e. writing a json or SQLite somewhere which tells you what's built and what's not.
I didn't mean that state (which is necessary for incremental builds IMHO, but that's a different debate),but the "essence" of the build, i.e. how to build all targets, why (dependencies), basically all the same infopresent in the set of human readable declarative files, but parsed/digested/expanded to be available toany other tool to consume as-is.
I cannot express enough the importance of both the concept of storing build-states, as well as the transitional data during a build.
There is no scenario as offensive to the senses as walking into work on Tuesday to be told "The version from Friday doesn't work, fix it" - Any programming house with a QC department has to deal with a simple and essential issue. People that are not programmers have to test your software - often some time after it was built.
The ease of automating the build process is only half the life-cycle of a build system, providing an interface through which build-states and errors can easily be retrieved is essential - often the tooling for such a scenario is done in house, presented as a intranet page to the QC staff.
In these situations Developers need feedback as to the build state, if possible before QC are aware a build has even been made - and in the event of failure, knowing what failed means knowing who needs to solve the issue.
In my companies scenario, we have fourteen software products - the nightly build system provides these as windows installers as well as Apple-DMG files.
Often errors are caused by simple network problems (system-admin issues), but some of our software is compiled with six different languages, through four different build processes - each has a different developer responsible.
I'm certainly not proposing a build system be some cure-all to these issue, however being capable of programmaticaly retrieving the state of a build, as well as the cause behind a failed build is a feature that should be seriously considered.