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

Bitbucket Server Integration plugin sends wrong ref to build status

    • 4.1.2

      When sending build status to BitBucket, pull request ref name is send instead of an actual source branch ref name. In effect, BB doesn't show Jenkins builds, no matter the status.
       

      Expected result: plugin should input an actual source branch name, for example: refs/heads/feature/JIRA-1234_new_feature. Value null would also be acceptable, considering Bitbucket PR view also lists such build statuses (that's how it worked on 4.0.0 plugin version).
       

      Actual result: plugin inserts ref for pull requests, for example: refs/heads/PR-123. BB updates previous build statuses which removes all past statuses from the list.
       

      Workaround: update values in Bitbucket database, setting correct ref or removing it:

      -- postgresql example
      update bb_build_status set ref=null where where ref like 'refs/heads/PR-%'; 

      The problem is, it will be set again during the next job launch, so plugin downgrade is needed in addition to above. Optionally, some job, running above SQL. Although, such approach is not recommended by Atlassian.

      Not sure if this is problem with our Bitbucket version? (8.19.6) Even if, the plugin should probably take into account older BB versions.

          [JENKINS-74782] Bitbucket Server Integration plugin sends wrong ref to build status

          Jakub Glazik added a comment -

          Source for how PR works: https://community.atlassian.com/t5/Bitbucket-questions/Builds-not-appearing-in-pull-requests/qaq-p/1777235

          For commit statuses to show on the pull request page the following criteria needs to be met:

          • the commit has of the commit status matches the current commit has of the source PR branch
          • if the commit status refname is null or it matches the branch name of the source branch.

          Jakub Glazik added a comment - Source for how PR works: https://community.atlassian.com/t5/Bitbucket-questions/Builds-not-appearing-in-pull-requests/qaq-p/1777235 For commit statuses to show on the pull request page the following criteria needs to be met: the commit has of the commit status matches the current commit has of the source PR branch if the commit status refname is null or it matches the branch name of the source branch .

          Jim added a comment - - edited

          Our company is hitting the same problem as described in this Jira when we try and upgrade our Bitbucket Server Integration plugin from the 4.0.0 release to the 4.1.0 or 4.1.1 release.

          From the builds running in Jenkins I was able to see a difference in the "Posting build status" message between the old and new plugin versions:

          Output from running w/ the 4.0.0 version of the plugin

          Posting build status of INPROGRESS to Bitbucket - Azure for commit id [79db0926c30a409d4522767b240f4083ade4edc8] and ref 'null'
          

          Output from running w/ the 4.1.1 version of the plugin

          Posting build status of INPROGRESS to Bitbucket - Azure for commit id [79db0926c30a409d4522767b240f4083ade4edc8] and ref 'refs/heads/PR-2'
          

          Based of the comment that rzabcio added, and the link provided it seems that providing the ref (not passing in 'null') the status posting just seems to break.

          When I look in the git repository associated with that Bitbucket repo, I don't see a ref that corresponds to 'PR-2'. Obviously there is a ref for the actual branch name, which makes me wonder if the plugin is assuming the incorrect ref by mistake?

          I don't know if it helps, but we're running the following version of Bitbucket Data Center:
          Atlassian Bitbucket v8.13.1

          Jim added a comment - - edited Our company is hitting the same problem as described in this Jira when we try and upgrade our Bitbucket Server Integration plugin from the 4.0.0 release to the 4.1.0 or 4.1.1 release. From the builds running in Jenkins I was able to see a difference in the "Posting build status" message between the old and new plugin versions: Output from running w/ the 4.0.0 version of the plugin Posting build status of INPROGRESS to Bitbucket - Azure for commit id [79db0926c30a409d4522767b240f4083ade4edc8] and ref 'null' Output from running w/ the 4.1.1 version of the plugin Posting build status of INPROGRESS to Bitbucket - Azure for commit id [79db0926c30a409d4522767b240f4083ade4edc8] and ref 'refs/heads/PR-2' Based of the comment that rzabcio added, and the link provided it seems that providing the ref (not passing in 'null') the status posting just seems to break. When I look in the git repository associated with that Bitbucket repo, I don't see a ref that corresponds to 'PR-2'. Obviously there is a ref for the actual branch name, which makes me wonder if the plugin is assuming the incorrect ref by mistake? I don't know if it helps, but we're running the following version of Bitbucket Data Center: Atlassian Bitbucket v8.13.1

          Jim added a comment - - edited

          I did some more digging, and I think I found the code from their GitHub page which is getting the ref to use when updating the build status.

          src/main/java/com/atlassian/bitbucket/jenkins/internal/status/LocalSCMListener.java

              @CheckForNull
              private String getRefFromEnvironment(Map<String, String> env, GitSCM scm) {
                  // If the pull request source commit is specified we do not need to specify the ref
                  if (StringUtils.isNotBlank(env.get(PULL_REQUEST_SOURCE_COMMIT))) {
                      return null;
                  }
          
                  String refId = StringUtils.stripToNull(env.get(GitSCM.GIT_BRANCH));
                  if (refId == null) {
                      return null;
                  }
          
                  if (StringUtils.isNotBlank(env.get(TAG_SOURCE_COMMIT))) {
                      return env.get(TAG_SOURCE_COMMIT);
                  }
          
                  // Branches are in the form of the result of a git fetch, prepended with the repository name. The Git SCM
                  // can strip the repo name (if it's found in the list of remote configs), and we append refs/heads afterwards.
                  return BRANCH_PREFIX + scm.deriveLocalBranchName(refId);
              }
          

          I updated my testing pipeline to print out the environment variables and see the following:

          GIT_BRANCH=PR-2
          

          I believe that is where the incorrect ref is coming from, at least in terms of where the plugin is grabbing it.

          I do see another environment variable which seems like it would grab the correct branch name:

          CHANGE_BRANCH=jim_branch
          

          I believe if that environment variable was used, or if it went back to using null the build status notifier would work once again.


          UPDATE

          I reverted back to the 4.0.0 version of the plugin, since the code I posted above doesn't seem to have changed much since the 4.0.0 release of the plugin.

          When I did so, and I looked at the environment print out I added I now see:

          CHANGE_BRANCH=jim_branch
          GIT_BRANCH=origin/master
          

          I still need to figure out how that environment variable is getting controlled as part of this plugin and how it changed between releases.

          Jim added a comment - - edited I did some more digging, and I think I found the code from their GitHub page which is getting the ref to use when updating the build status. src/main/java/com/atlassian/bitbucket/jenkins/internal/status/LocalSCMListener.java @CheckForNull private String getRefFromEnvironment(Map< String , String > env, GitSCM scm) { // If the pull request source commit is specified we do not need to specify the ref if (StringUtils.isNotBlank(env.get(PULL_REQUEST_SOURCE_COMMIT))) { return null ; } String refId = StringUtils.stripToNull(env.get(GitSCM.GIT_BRANCH)); if (refId == null ) { return null ; } if (StringUtils.isNotBlank(env.get(TAG_SOURCE_COMMIT))) { return env.get(TAG_SOURCE_COMMIT); } // Branches are in the form of the result of a git fetch, prepended with the repository name. The Git SCM // can strip the repo name ( if it's found in the list of remote configs), and we append refs/heads afterwards. return BRANCH_PREFIX + scm.deriveLocalBranchName(refId); } I updated my testing pipeline to print out the environment variables and see the following: GIT_BRANCH=PR-2 I believe that is where the incorrect ref is coming from, at least in terms of where the plugin is grabbing it. I do see another environment variable which seems like it would grab the correct branch name: CHANGE_BRANCH=jim_branch I believe if that environment variable was used, or if it went back to using null the build status notifier would work once again. UPDATE I reverted back to the 4.0.0 version of the plugin, since the code I posted above doesn't seem to have changed much since the 4.0.0 release of the plugin. When I did so, and I looked at the environment print out I added I now see: CHANGE_BRANCH=jim_branch GIT_BRANCH=origin/master I still need to figure out how that environment variable is getting controlled as part of this plugin and how it changed between releases.

          Jim added a comment -

          I think I've taken my digging as far as I'm able.

          I cannot find in the code how the value of GIT_BRANCH is being set to a different values between the versions of the plugin.

          Really hopefully someone else can figure out what's going on.

          Jim added a comment - I think I've taken my digging as far as I'm able. I cannot find in the code how the value of GIT_BRANCH is being set to a different values between the versions of the plugin. Really hopefully someone else can figure out what's going on.

            Unassigned Unassigned
            rzabcio Jakub Glazik
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: