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

Bitbucket Branch Source Plugin: changes are missing for builds again

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Critical Critical
    • None
    • Jenkins ver. 2.89.2 / Bitbucket Branch Source Plugin 2.1.2

      This issue back JENKINS-44365 again after release  Bitbucket Branch Source Plugin 2.2.6. It works in 2.2.5 but not in 2.2.6+.

      Thanks.

          [JENKINS-48687] Bitbucket Branch Source Plugin: changes are missing for builds again

          Benny Bozg added a comment -

          Same here for 2.2.8, downgraded to 2.2.3 to get it to work (downgrade plugin button in jenkins suggested this version).

          Jenkins 2.97

          Benny Bozg added a comment - Same here for 2.2.8, downgraded to 2.2.3 to get it to work (downgrade plugin button in jenkins suggested this version). Jenkins 2.97

          James Hogarth added a comment -

          So this bit us on our test instance today, when evaluating some global library changes.

          A little bit of poking shows it to be a "regression" from this issue: https://issues.jenkins-ci.org/browse/JENKINS-42518

          It looks like when there's only a lightweight checkout (to just grab the Jenkinsfile for processing) then currentBuild.changeSets does not get populated.

          It appears to be sufficient to do an

          scm checkout

          at any point before poking currentBuild.changeSets (even outside of a stage to make it invisible in the background). 

          node {
            deleteDir()
            checkout scm
            deleteDir()
          }
          
          stage("do stuff") {
            echo currentBuild.changeSets
          }
          

           Doing something like that, so checking changesets happens after a full checkout, "works" as a workaround at the cost of the weight of the checkout.

          Presumably the Bitbucket api or something will need to be poked if there's only a lightweight checkout happening as part of BitbucketSCMFile to populate the variable properly when there is no full checkout yet.

          James Hogarth added a comment - So this bit us on our test instance today, when evaluating some global library changes. A little bit of poking shows it to be a "regression" from this issue: https://issues.jenkins-ci.org/browse/JENKINS-42518 It looks like when there's only a lightweight checkout (to just grab the Jenkinsfile for processing) then currentBuild.changeSets does not get populated. It appears to be sufficient to do an scm checkout at any point before poking currentBuild.changeSets (even outside of a stage to make it invisible in the background).  node { deleteDir() checkout scm deleteDir() } stage("do stuff") { echo currentBuild.changeSets }  Doing something like that, so checking changesets happens after a full checkout, "works" as a workaround at the cost of the weight of the checkout. Presumably the Bitbucket api or something will need to be poked if there's only a lightweight checkout happening as part of BitbucketSCMFile to populate the variable properly when there is no full checkout yet.

          benoit guerin added a comment - - edited

          Don't know if it is the same problem or another, but for me, the symptoms are the same as JENKINS-44849 for the github plugin : first build of a branch / PR has empty changeset. From 2nd build, changeset are correctly set.

          And forcing a scm step, after cleaning the workspace does not help

          I started diging but got lost ... Can some Jenkins expert help me find the culprit piece of code ? stephenconnolly amuniz casz ?

          benoit guerin added a comment - - edited Don't know if it is the same problem or another, but for me, the symptoms are the same as  JENKINS-44849 for the github plugin : first build of a branch / PR has empty changeset. From 2nd build, changeset are correctly set. And forcing a scm step, after cleaning the workspace does not help I started diging but got lost ... Can some Jenkins expert help me find the culprit piece of code ? stephenconnolly amuniz casz ?

          benoit guerin added a comment -

          Ok, got it, it is in the git plugin, which does not compute changelog for the first build of a new branch : JENKINS-14138

          benoit guerin added a comment - Ok, got it, it is in the git plugin, which does not compute changelog for the first build of a new branch :  JENKINS-14138

          benoit guerin added a comment -

          Also, for global pipeline librairies, be aware that, by defaut, changelog is not computed for them.

          You can override this behaviour on library configuration or in a Jenkinsfile, like said in the doc :

          benoit guerin added a comment - Also, for global pipeline librairies, be aware that, by defaut, changelog is not computed for them. You can override this behaviour on library configuration or in a Jenkinsfile, like said in the doc :

          Nikolas Falco added a comment -

          Is this issue still present in the latest plugin version?

          I mean, expect the first commit of the job for which is not possible understand from which commit start to compare changes.

          Nikolas Falco added a comment - Is this issue still present in the latest plugin version? I mean, expect the first commit of the job for which is not possible understand from which commit start to compare changes.

            nfalco Nikolas Falco
            argus_k Dmytro Kozlovskyi
            Votes:
            8 Vote for this issue
            Watchers:
            11 Start watching this issue

              Created:
              Updated: