Builds triggered by the amount of changes
In a discussion about build infrastructure efficiency that was centered on how to distribute multiple configurations over multiple days & weeks to reduce the overall cost, I realized that what’s really needed is a mechanism to trigger a build based on the amount of new changes that have been added to different areas of a project.
I think that because, in this context, time acts as an approximation of how quickly things change and we all know software development work is not evenly distributed and the frequency of our builds should match that.
Why is that interesting? Because the primary goal of an integration test run is to help people figure out if any breaking change was introduced. A failed build is only actionable if the list of changes is something a human can act on. That limit is not very high and a time based trigger could error on the wrong side.
It would also be cool if when a build fails and it includes a larger number of changes if I could have a way to define interesting intermediate points and trigger multiple new executions in parallel to identify the root cause.
Does Jenkins already have a plugins like this? What do you do to make complex builds more efficient? How do you go about splitting a large matrix of integration tests?