Uploaded image for project: 'Tools (JBoss Tools)'
  1. Tools (JBoss Tools)
  2. JBIDE-18662

use getProjectSHAs.sh to control when to run aggregate builds, instead of doing composite site installs


    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Major Major
    • 4.3.0.Alpha1
    • 4.2.0.CR2
    • build
    • None

      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.

            nickboldt Nick Boldt
            nickboldt Nick Boldt
            0 Vote for this issue
            2 Start watching this issue