Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-1066

Convert Buildbot to on-git change triggert instead of cron job trigger

    Details

    • Team:
      SQuaRE

      Description

      Convert from the current cron job which initiates a trigger when any repo changes to providing an on-git-change trigger for each repository.

      Need clarification from Kian-Tat Lim on meaning of product - package based (lsst_distrib) or project group based (sims, DB, DM-core)

      • "get the master builds triggered on git-change instead of via cron and separated by product"

        Attachments

          Activity

          Hide
          ktl Kian-Tat Lim added a comment -

          In my ideal world, each top-level product (currently lsst_distrib, qserv, and lsst_sims) should have its own git-triggered builder, manually-triggered builder, nightly builder, and weekly builder – and each builder would have its own swimlane in the waterfall page and its own notification E-mail list.

          Show
          ktl Kian-Tat Lim added a comment - In my ideal world, each top-level product (currently lsst_distrib , qserv , and lsst_sims ) should have its own git-triggered builder, manually-triggered builder, nightly builder, and weekly builder – and each builder would have its own swimlane in the waterfall page and its own notification E-mail list.
          Hide
          robyn Robyn Allsman [X] (Inactive) added a comment -

          Work on this was delayed since buildbot's interface to git repos requires a separate event handler for each repository.

          Now, after working with the hourly cron scheduled master rebuilds, I find the master build does not catch as many branch merges in transition as the previous, more frequent scheduler experienced. The application group's updates usually incorporate many repos which lengthens the time when a scheduled build could be triggered mid-way though the packages' merges.

          And, since every user is supposed to test their private branch(s) on buildbot prior to merging to master, the final build of the merged master is lightweight since the individual packages had already been built against the correct dependencies.

          Show
          robyn Robyn Allsman [X] (Inactive) added a comment - Work on this was delayed since buildbot's interface to git repos requires a separate event handler for each repository. Now, after working with the hourly cron scheduled master rebuilds, I find the master build does not catch as many branch merges in transition as the previous, more frequent scheduler experienced. The application group's updates usually incorporate many repos which lengthens the time when a scheduled build could be triggered mid-way though the packages' merges. And, since every user is supposed to test their private branch(s) on buildbot prior to merging to master, the final build of the merged master is lightweight since the individual packages had already been built against the correct dependencies.
          Hide
          ktl Kian-Tat Lim added a comment -

          I'm not sure I understand the comment. If multi-package merges are being caught in transition, we should increase the delay from the git trigger to the build.

          The primary goals here are 1) to reduce the total number of builds, especially ones that add no value, and 2) to reduce the time between a merge push and the next build.

          Show
          ktl Kian-Tat Lim added a comment - I'm not sure I understand the comment. If multi-package merges are being caught in transition, we should increase the delay from the git trigger to the build. The primary goals here are 1) to reduce the total number of builds, especially ones that add no value, and 2) to reduce the time between a merge push and the next build.
          Hide
          robyn Robyn Allsman [X] (Inactive) added a comment -

          In the olde days when buildbot was triggered more frequently (first every minute, then every 10 minutes), a multi-package merging would initiate builds in the middle of that sequential merge operation. Now with the scheduled builds occurring at 1 hour intervals (done in Sept by Frossie), I have not seen that problem. The current period seems fine.

          Users should always ensure their master-merged packages will work by forcing a branch build prior to the merge to master. I don't know how many botches have been averted but we do seem to have less developer-error build failures on the master branch in recent months.

          I understand your goals for this ticket. I'll reset to ToDo and reassign to Frossie so she can schedule it.

          Show
          robyn Robyn Allsman [X] (Inactive) added a comment - In the olde days when buildbot was triggered more frequently (first every minute, then every 10 minutes), a multi-package merging would initiate builds in the middle of that sequential merge operation. Now with the scheduled builds occurring at 1 hour intervals (done in Sept by Frossie), I have not seen that problem. The current period seems fine. Users should always ensure their master-merged packages will work by forcing a branch build prior to the merge to master. I don't know how many botches have been averted but we do seem to have less developer-error build failures on the master branch in recent months. I understand your goals for this ticket. I'll reset to ToDo and reassign to Frossie so she can schedule it.

            People

            • Assignee:
              frossie Frossie Economou
              Reporter:
              robyn Robyn Allsman [X] (Inactive)
              Watchers:
              Kian-Tat Lim, Robyn Allsman [X] (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Summary Panel