Hi,
I am not sure I understand the proposed change. Currently the product build is triggered by the component builds, core, tooling and so on. I assumed that the reason for the product build to be triggered by the component builds was due to that the product build used the output from the component builds in some way.
But now you are saying that the product build can be triggered "on its own", which I interpret as if it does not really depend on the component builds have been run at all. Is that correct? Then what is the purpose of the individual component builds? I am bit confused here...
And when you say each 30 minutes, I assume that you mean that the product build should check if there has been an SCM change, i.e. a commit being merged, each 30 minutes. But why should that be check only be made each 30 minutes? That I assume could be checked each 15 minutes as for the component builds. Otherwise you can theoretically have to wait for 30 minutes before the build is triggered (in case the merge is committed right after the last SCM poll) and then the build that takes 17-20 minutes, i.e. up to 50 minutes.
Sure, that is much better than the current situation where you need to wait up to 15 minutes for the SCM poll on the component builds, then build core and tooling in parallell (I assume a few minutes), then build product for up to 24 minutes, in parallel with the second tooling build,, and then the second product build (triggered by the second tooling build) for 24 minutes more, which adds up to more than an hour. Still not sure if I can use the first product build or if I need to wait for the second one.
I thought that the triggering of builds could be made a bit more intelligent, i.e. if it is concluded that a commit impacts both core and tooling, then skip triggering tooling and only trigger core, since you know that core in its turn will trigger the build of tooling. That would avoid the double builds of tooling and product.
/Peter Cigéhn