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

Global Shared Library git ref overrides the project repo git info

    • Icon: Bug Bug
    • Resolution: Cannot Reproduce
    • Icon: Major Major
    • Jenkins 2.19.1(installed via apt)
      master and nodes (via ssh): ubuntu 14.04.5 LTS, openJDK 1.8.0_91

      bitbucket-build-status-notifier 1.3.1
      pipeline: shared groovy libraries 2.5
      pipeline remote loader 1.3
      git plugin 3.0.1

      My organization has been using Jenkins 2.0 and Pipelines for several months. We've reached a critical point where we need a global library to consolidate functionality and reduce configuration drift of our Jenkinsfiles and scripts. I created a git repo in our Bitbucket team to hold common functions, the first of which are notifications classes for sending build status to Hipchat and Bitbucket (e.g. src/com/team/notifications/Bitbucket.groovy):

      +package com.team.jenkins.notifications
      +
      +class Bitbucket implements Serializable {
      +
      +    def script
      +    Bitbucket(script) {
      +        this.script = script
      +    }
      +
      +    def started() {
      +        this.script.bitbucketStatusNotify (
      +            buildState: 'INPROGRESS'
      +        )
      +    }
      +
      +    def succeeded() {
      +        this.script.bitbucketStatusNotify (
      +            buildState: 'SUCCESSFUL'
      +        )
      +    }
      +
      +    def failed(stage, err) {
      +        this.script.bitbucketStatusNotify (
      +            buildState: 'FAILED',
      +            buildDescription: "Build failed during ${stage}: ${err}"
      +        )
      +    }
      +}
      

      Our development workflow depends on Jenkins build approvals of pull requests, using the Bitbucket build status notifier plugin. The above class "works", in that it sends build status notifications to bitbucket, but the problem is that it is always sending those notifications to the shared library repo, not the repo that is being built (e.g. one of our Java libraries or webapps).

      I have tested the above library as both a class and as a global var implementation, both explicitly and implicitly loaded into the pipeline script. I have also confirmed that the normal non-shared-library usage of the bitbucket-status-notifier plugin is affected by the shared library git repo, so the plugin can't be used at all, it seems, if there's a shared library brought into a pipeline job. Here's its usage as an explicit library:

      @Library('common-jenkins') import com.team.jenkins.notifications.Bitbucket
      def bitbucketer
      
      node() {
          stage('init) {
              git url: 'https://user@bitbucket.org/team/repo.git'
              bitbucketer = new Bitbucket(this)
              sh './gradlew clean'
              bitbucketer.started()
          }
      
          stage('build') {
              try {
                  sh './gradlew build'
              } catch (Exception e) {
                  bitbucketer.failed('build', e)
              }
              bitbucketer.succeeded()
          }
      }
      

      As has already been reported on JENKINS-40150 and JENKINS-41442, the git repo information of the shared library is bleeding into the execution of the pipeline job. We have other pipeline operations that reference Git info, so I am unable to expand actual usage of the shared library to our other projects, with this interference.

          [JENKINS-41602] Global Shared Library git ref overrides the project repo git info

          Scott Russell added a comment -

          jglick - that's interesting. Would doing something like below get my library loaded into a pipeline without affecting any git-aware pipeline steps? (And maybe this bitbucketStatusNotifier plugin usage isn't the right example for reasons above, but is along the lines of your idea of checkout + load implementation.)

          def bitbucketLib, bitbucketer
          
          node() {
              stage('init) {
                  checkout changelog: false, poll: false, 
                      scm: [$class: 'GitSCM', 
                          branches: [[name: '*/master']], 
                          doGenerateSubmoduleConfigurations: false, 
                          extensions: [
                              [$class: 'IgnoreNotifyCommit'], 
                              [$class: 'RelativeTargetDirectory', relativeTargetDir: 'common-jenkins']
                          ], 
                          submoduleCfg: [], 
                          userRemoteConfigs: [
                              [credentialsId: 'bitbucket-jenkins-user', url: 'https://User@bitbucket.org/company/common-jenkins.git']
                          ]
                      ]
                  bitbucketLib = load 'common-jenkins/src/com/team/jenkins/notifications/Bitbucket.groovy'
                  bitbucketer = new bitbucketLib.Bitbucket(this)
          
                  git url: 'https://user@bitbucket.org/team/repo.git'
                  sh './gradlew clean'
                  bitbucketer.started()
              }
          
              stage('build') {
                  try {
                      sh './gradlew build'
                  } catch (Exception e) {
                      bitbucketer.failed('build', e)
                  }
                  bitbucketer.succeeded()
              }
          }
          

          Scott Russell added a comment - jglick - that's interesting. Would doing something like below get my library loaded into a pipeline without affecting any git-aware pipeline steps? (And maybe this bitbucketStatusNotifier plugin usage isn't the right example for reasons above, but is along the lines of your idea of checkout + load implementation.) def bitbucketLib, bitbucketer node() { stage('init) { checkout changelog: false , poll: false , scm: [$class: 'GitSCM' , branches: [[name: '*/master' ]], doGenerateSubmoduleConfigurations: false , extensions: [ [$class: 'IgnoreNotifyCommit' ], [$class: 'RelativeTargetDirectory' , relativeTargetDir: 'common-jenkins' ] ], submoduleCfg: [], userRemoteConfigs: [ [credentialsId: 'bitbucket-jenkins-user' , url: 'https: //User@bitbucket.org/company/common-jenkins.git' ] ] ] bitbucketLib = load 'common-jenkins/src/com/team/jenkins/notifications/Bitbucket.groovy' bitbucketer = new bitbucketLib.Bitbucket( this ) git url: 'https: //user@bitbucket.org/team/repo.git' sh './gradlew clean' bitbucketer.started() } stage( 'build' ) { try { sh './gradlew build' } catch (Exception e) { bitbucketer.failed( 'build' , e) } bitbucketer.succeeded() } }

          Jesse Glick added a comment -

          I do not know much about this plugin so I cannot say.

          Jesse Glick added a comment - I do not know much about this plugin so I cannot say.

          Jason MCDev added a comment -

          I am having the same issue here. I have a multi-scm ( Git ) project with a global library from source.

          No matter what I try, the notify sends the notification based on the sha from the global library - in my case I see it send three notifications, as I have three repos in my project, but all to the same sha of the global library.

          I just moved to the global library and was about to turn on gated check-ins for our team which is now blocked.  I do think that the Bitbucket plugin works with auto notification, but I had other issues with that particular plugin and moved back to the SCM git plugin.  This is a real blocker for us.

          Jason MCDev added a comment - I am having the same issue here. I have a multi-scm ( Git ) project with a global library from source. No matter what I try, the notify sends the notification based on the sha from the global library - in my case I see it send three notifications, as I have three repos in my project, but all to the same sha of the global library. I just moved to the global library and was about to turn on gated check-ins for our team which is now blocked.  I do think that the Bitbucket plugin works with auto notification, but I had other issues with that particular plugin and moved back to the SCM git plugin.  This is a real blocker for us.

          Scott Russell added a comment -

          Reporting now that I'm no longer seeing this problem on my system. I'm not sure when it started working correctly (including with Bitbucket sources on multibranch pipeline jobs). Our global library is set up in Jenkins -> "Configure System" as a "Global Pipeline Library", with "Load Implicitly" turned off and "Ignore on push notifications" turned on.

          We are running Jenkins 2.46.2, with Bitbucket Branch Source 2.2.2, Pipeline 2.5, Pipeline: Shared Groovy Libraries 2.8, and Pipeline: Multibranch 2.16.

          Scott Russell added a comment - Reporting now that I'm no longer seeing this problem on my system. I'm not sure when it started working correctly (including with Bitbucket sources on multibranch pipeline jobs). Our global library is set up in Jenkins -> "Configure System" as a "Global Pipeline Library", with "Load Implicitly" turned off and "Ignore on push notifications" turned on. We are running Jenkins 2.46.2, with Bitbucket Branch Source 2.2.2, Pipeline 2.5, Pipeline: Shared Groovy Libraries 2.8, and Pipeline: Multibranch 2.16.

          John Carter added a comment -

          We are seeing this issue.

           

          Jenkins 2.88

          Bitbucket Branch Source 2.2.3

          Pipeline 2.5

          Pipeline: Shared Groovy Libraries 2.9

          Pipeline: Multibranch 2.16

           

           global library is set up in Jenkins -> "Configure System" as a "Global Pipeline Library", with "Load Implicitly" off, " Include @Library changes in job recent changes" off.

          John Carter added a comment - We are seeing this issue.   Jenkins 2.88 Bitbucket Branch Source 2.2.3 Pipeline 2.5 Pipeline: Shared Groovy Libraries 2.9 Pipeline: Multibranch 2.16    global library is set up in Jenkins -> "Configure System" as a "Global Pipeline Library", with "Load Implicitly" off, " Include @Library changes in job recent changes" off.

          Thomas Tardy added a comment -

          +1

          We are having the same issue as therefromhere1 in Jenkins 2.90. When I add the global library, the git repo info is changed to the one of the shared library.

          Thomas Tardy added a comment - +1 We are having the same issue as therefromhere1 in Jenkins 2.90. When I add the global library, the git repo info is changed to the one of the shared library.

          +1 

          We are also having the same issue as John and Thomas. flagbit could you reopen this and try to reproduce?

          Maxime Charron added a comment - +1  We are also having the same issue as John and Thomas. flagbit could you reopen this and try to reproduce?

          flagbit or you could look at this PR which provides a nice workaround

          Maxime Charron added a comment - flagbit or you could look at this PR  which provides a nice workaround

          Rohit Kumar added a comment -

          Have the same issue with Jenkins version 2.134, even passing the optional parameter for commit overrides with the shared library one. 

           
          bitbucketStatusNotify(
          buildState: 'SUCCESSFUL',
          commitId: 'xxxxxxxxx' )

          Rohit Kumar added a comment - Have the same issue with Jenkins version 2.134, even passing the optional parameter for commit overrides with the shared library one.    bitbucketStatusNotify( buildState: 'SUCCESSFUL', commitId: 'xxxxxxxxx' )

          Raphael added a comment - - edited

          FWIW, this "information leak" is present even without Bitbucket notifications. For Multi-Branch Pipelines, BlueOcean indicates change sets for both the current repo and the shared library:

          Not only can that be mildly confusing ("What are those guys doing in my repo?!") but also, as pertaining to this here issue, every commit on the shared library gets hundreds of associated builds from all over.

          Raphael added a comment - - edited FWIW, this "information leak" is present even without Bitbucket notifications. For Multi-Branch Pipelines, BlueOcean indicates change sets for both the current repo and the shared library: Not only can that be mildly confusing ("What are those guys doing in my repo?!") but also, as pertaining to this here issue, every commit on the shared library gets hundreds of associated builds from all over.

            flagbit Antonio Mansilla
            amundsenjunior Scott Russell
            Votes:
            3 Vote for this issue
            Watchers:
            11 Start watching this issue

              Created:
              Updated:
              Resolved: