Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-64193

Perforce plugin incorrectly triggers multibranch builds

    XMLWordPrintable

Details

    Description

      Due to the change done for JENKINS-61745 multibranch pipeline builds that track Perforce streams end up getting triggered for any new changelist on the Perforce server as soon as the stream in question is over 1000 revisions behind the latest revision on the server. In our case this translates to any stream that hasn't had a change submitted in about a week. With the number of streams that we use this ends up triggering enough builds often enough to completely clog up our build pipeline meaning we have had to disable automatic multibranch builds.

      The bug is rooted in how the Perforce plugin determines the latest change for a stream when performing branch indexing.

      The problematic code is in ClientHelper.java method getClientHead(). The code determines the latest change on the server, gets the changes for the given path that has happened between the latest and (latest - 1000), and if there are no changes it returns the latest server change as the latest change to the path. The last conditional at https://github.com/jenkinsci/p4-plugin/blob/7cd96e85532b1fdfc918eeef525cc2d23789471a/src/main/java/org/jenkinsci/plugins/p4/client/ClientHelper.java#L1113-L1121 should be changed to return a value that indicates that there have been no changes in the given revision range, and in the case of multibranch builds this should result in no build being triggered.

      Attachments

        Activity

          p4paul Paul Allen added a comment -

          Released in 1.11.2

          p4paul Paul Allen added a comment - Released in 1.11.2
          p4paul Paul Allen added a comment -

          Ready for release.

          p4paul Paul Allen added a comment - Ready for release.
          p4karl Karl Wirth added a comment -

          Hi ihalila_ser  - Sorry for the delay. I didnt see an email about this .

          Up to 30,000 should be OK. After that there can be a performance impact if you have a very large change and rev table.

           

           

          p4karl Karl Wirth added a comment - Hi ihalila_ser   - Sorry for the delay. I didnt see an email about this . Up to 30,000 should be OK. After that there can be a performance impact if you have a very large change and rev table.    
          ihalila_ser Ilkka Halila added a comment -

          I can do that to alleviate the problem, though is there a risk that it will cause considerable load on our Perforce server if I set the number very high? I'm asking because of the mentions of load in the original task.

          ihalila_ser Ilkka Halila added a comment - I can do that to alleviate the problem, though is there a risk that it will cause considerable load on our Perforce server if I set the number very high? I'm asking because of the mentions of load in the original task.
          p4karl Karl Wirth added a comment -

          Hi ihalila_ser - So I'm guessing you already know the workaround is to change 'Head change query limit':

            Jenkins > Manage Jenkins > Configure System > Head change query limit

          and this job is an enmhancement to get the default behavior changed. Is that correct?

          p4karl Karl Wirth added a comment - Hi ihalila_ser - So I'm guessing you already know the workaround is to change 'Head change query limit':   Jenkins > Manage Jenkins > Configure System > Head change query limit and this job is an enmhancement to get the default behavior changed. Is that correct?

          People

            p4paul Paul Allen
            ihalila_ser Ilkka Halila
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: