Nick said:

>> How else would you determine if/when the aggregates should be built?
>> Using a variation on getProjectSHAs.sh script and diffing the last run
>> w/ the current run? Or something else?

And Mickael replied:

> It could be built as often as the composite-install job runs because it
> takes more or less the same time, and even if one builds aggregator for
> nothing, it won't change the aggregate repository output (only the
> content.jar and artifact.jar would be updated to a newer timestamp).
> So since it's totally possible directly aggregate whenever something
> changes for the same price, it seems more straightforward to do it
> instead of introducing an intermediary control job, which can have bugs.

Then Nick said:

Yeah, I still like the fact that the composite install job performs an install test... but maybe it can be downstream of the TP change and NOT upstream of the aggregate builds?

I could look at creating a more "diffable digest" as output of getProjectSHAs.sh and have that run in Jenkins as the gatekeeper (or keymaster?) for when to run aggregates.