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

Activity/Branch dashboard show pipeline library commit instead of actual built commit

    Details

    • Epic Link:
    • Sprint:
      Blue Ocean - 1.1-beta-1, Blue Ocean - 1.1-beta2
    • Similar Issues:

      Description

      Notes
      We don't want to be showing the commits from a shared library in this case. We need to do some testing here and find out why shared library changes are coming through and not the application code. We suspect that we pick the first grouping of change sets and this happens to be the changeset of the shared library in this scenario.

       

      Expected behavior: 

      Show only the latest commit from the repository that the pipeline originates from (ie where the Jenkinsfile is changed) that was triggering the pipeline. 

      Any other commits are to be ignored as part of this. They will show up in the design shown in: https://issues.jenkins-ci.org/browse/JENKINS-39860

       

      Original request
      Heyo!

      I'm using pipelines for a while now and have most of the steps used abstracted away into a pipeline library in a git repository. I now installed blue ocean today and was scrolling through my builds which had all suprisingly the same commit shown:

       

      Turns out this is actually the latest commit of the pipeline library I'm using as seen in the console log:

       

      Obtained Jenkinsfile from ccf54369437ff7dcd66b888fde50b19bad7ecf23
      
      Loading library mylib@master
      > git rev-parse --is-inside-work-tree # timeout=10
      Setting origin to /mnt/devops
      > git config remote.origin.url /mnt/devops # timeout=10
      Fetching origin...
      Fetching upstream changes from origin
      > git --version # timeout=10
      > git fetch --tags --progress origin +refs/heads/:refs/remotes/origin/
      > git rev-parse master^{commit} # timeout=10
      > git rev-parse origin/master^{commit} # timeout=10
      > git rev-parse --is-inside-work-tree # timeout=10
      Fetching changes from the remote Git repository
      > git config remote.origin.url /mnt/devops # timeout=10
      Fetching upstream changes from /mnt/devops
      > git --version # timeout=10 > git fetch --tags --progress /mnt/devops +refs/heads/:refs/remotes/origin/
      Checking out Revision 76cca6a9021830b3850eab338050c1d839d7b318 (master) > git config core.sparsecheckout # timeout=10
      > git checkout -f 76cca6a9021830b3850eab338050c1d839d7b318
      > git rev-list 76cca6a9021830b3850eab338050c1d839d7b318 # timeout=10
      
      [Pipeline] node Running on master in /var/jenkins_home/workspace/PR-63-WGSBDQPE6N2TEWS2C25CRCFXVLMNQURTXNY3KELAD4YZHGLFQIPA
      [Pipeline] {
      [Pipeline] checkout
      > git rev-parse --is-inside-work-tree # timeout=10
      Fetching changes from 2 remote Git repositories
      > git config remote.origin.url https://github.com/sneils/some-repo.git # timeout=10
      Fetching upstream changes from https://github.com/sneils/some-repo.git
      > git --version # timeout=10 using GIT_ASKPASS to set credentials checkout
      > git fetch --tags --progress https://github.com/sneils/some-repo.git +refs/heads/:refs/remotes/origin/
      > git config remote.origin1.url https://github.com/sneils/some-repo.git # timeout=10
      Fetching upstream changes from https://github.com/sneils/some-repo.git using GIT_ASKPASS to set credentials checkout
      > git fetch --tags --progress https://github.com/sneils/some-repo.git +refs/pull//head:refs/remotes/origin/pr/
      Checking out Revision ccf54369437ff7dcd66b888fde50b19bad7ecf23 (PR-63)
      > git config core.sparsecheckout # timeout=10
      > git checkout -f ccf54369437ff7dcd66b888fde50b19bad7ecf23
      ...
      

       

      I would expect this to be the commit of the actually checked out repository.

       

        Attachments

          Issue Links

            Activity

            Hide
            jamesdumay James Dumay added a comment -
            Show
            jamesdumay James Dumay added a comment - Michael Neale nice - all Brody Maclean
            Hide
            vivek Vivek Pandey added a comment -

            In blueocean we were computing commit id of current scm checkout by using BuildData action. BuildData action always points to shared library commit id. For this reason all commit ids always pointed to shared library. Hard to tell if thats right behavior reading it's Javadoc.

            However using SCMRevisionAction, we get checked out repo's commit id correctly. I tested it with multiple branches and it seems to behave well.

            I have PR opened with this change, https://github.com/jenkinsci/blueocean-plugin/pull/1010. Jesse Glick James Dumay PTAL.

            Show
            vivek Vivek Pandey added a comment - In blueocean we were computing commit id of current scm checkout by using BuildData action. BuildData action always points to shared library commit id. For this reason all commit ids always pointed to shared library. Hard to tell if thats right behavior reading it's Javadoc. However using SCMRevisionAction, we get checked out repo's commit id correctly. I tested it with multiple branches and it seems to behave well. I have PR opened with this change, https://github.com/jenkinsci/blueocean-plugin/pull/1010 . Jesse Glick James Dumay PTAL.
            Hide
            jamesdumay James Dumay added a comment -

            Will be released in Blue Ocean 1.1

            Show
            jamesdumay James Dumay added a comment - Will be released in Blue Ocean 1.1
            Hide
            lalmeras Laurent Almeras added a comment -

            Hi,

            Sorry to comment again on a closed issue, but I am fighting with a similar issue with other plugins, and I am a bit lost on how to fix it.

            I encounter this issue (SHA retrieved from pipeline's lib instead of project) on github-plugin and gitlab-plugin (last version for each one). I open the following issues :

            For each plugin, revision information lookup is done with BuildData, and is buggy ; using SCMRevisionAction fixes the bug for github-plugin, but :

            • gitlab-plugin also uses BuildData to lookup remote url, this information is not accessible in SCMRevisionAction;
            • it seems to me that « BuildData containing pipeline's lib information » 's behavior is a regression, as it used to work;
            • I also think, but I'm not familiar with Jenkins API, that it is not a good choice to push pipeline's library information into BuildData.

            Maybe previous BuildData's behavior may be restored (and custom actions should be used to store pipeline's library information). If this is not the case, is there anyone willing to point out to Jenkins API allowing to mimic old behaviors ?

            Thanks.

            Show
            lalmeras Laurent Almeras added a comment - Hi, Sorry to comment again on a closed issue, but I am fighting with a similar issue with other plugins, and I am a bit lost on how to fix it. I encounter this issue (SHA retrieved from pipeline's lib instead of project) on github-plugin and gitlab-plugin (last version for each one). I open the following issues : gitlab : https://github.com/jenkinsci/gitlab-plugin/issues/553 github : https://issues.jenkins-ci.org/browse/JENKINS-40150 For each plugin, revision information lookup is done with BuildData, and is buggy ; using SCMRevisionAction fixes the bug for github-plugin, but : gitlab-plugin also uses BuildData to lookup remote url, this information is not accessible in SCMRevisionAction; it seems to me that « BuildData containing pipeline's lib information » 's behavior is a regression, as it used to work; I also think, but I'm not familiar with Jenkins API, that it is not a good choice to push pipeline's library information into BuildData. Maybe previous BuildData's behavior may be restored (and custom actions should be used to store pipeline's library information). If this is not the case, is there anyone willing to point out to Jenkins API allowing to mimic old behaviors ? Thanks.
            Hide
            jglick Jesse Glick added a comment -

            Please keep the conversation in open issues, not here.

            Show
            jglick Jesse Glick added a comment - Please keep the conversation in open issues, not here.

              People

              • Assignee:
                vivek Vivek Pandey
                Reporter:
                sneils Franz B.
              • Votes:
                2 Vote for this issue
                Watchers:
                11 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: