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

Shared libraries stopped loading with git tags. They only now work when I reference a git branch name

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      I have a shared library in my Jenkins server that I call "common-pipelines". From within my Jenkinsfile, I will call for a specific tagged version of the common-pipelines shared library to be loaded like this:

      @Library('common-pipelines@v9.4.4') _ 

      I was just alerted that the pipelines are erroring with the following message:

      Please make sure you have the correct access rights
      and the repository exists. 

      However, we aren't sure what changed. After much sanity checking, I was able to determine that this works normally if I call for a branch name rather than a github release (git tag).

      In other words, this works just fine:

       @Library('common-pipelines@myBranchName') _ 

      I am running the latest plugins.

        Attachments

          Issue Links

            Activity

            Hide
            piratejohnny Jon B added a comment -

            Update: I have been able to determine that this problem emerges when I upgrade from Jenkins 2.130 to Jenkins 2.133

            Show
            piratejohnny Jon B added a comment - Update: I have been able to determine that this problem emerges when I upgrade from Jenkins 2.130 to Jenkins 2.133
            Hide
            piratejohnny Jon B added a comment -

            Confirming that when we downgrade to 2.130, the original working behavior is restored.

            Show
            piratejohnny Jon B added a comment - Confirming that when we downgrade to 2.130, the original working behavior is restored.
            Hide
            markewaite Mark Waite added a comment -

            Did plugin versions change when you downgraded to 2.130 or when you upgraded to 2.133? In general, I would not expect a change of Jenkins version number to alter the specific behavior of the Pipeline code which loads library versions by tag or by branch name.

            There was a change in Git plugin 3.9.0 to restore the ability to load Pipeline shared libraries by SHA-1 in addition to loading them by branch name or tag.

            Show
            markewaite Mark Waite added a comment - Did plugin versions change when you downgraded to 2.130 or when you upgraded to 2.133? In general, I would not expect a change of Jenkins version number to alter the specific behavior of the Pipeline code which loads library versions by tag or by branch name. There was a change in Git plugin 3.9.0 to restore the ability to load Pipeline shared libraries by SHA-1 in addition to loading them by branch name or tag.
            Hide
            piratejohnny Jon B added a comment - - edited

            Mark Waite I am now running "Git plugin 3.9.0" with Jenkins 2.130 and things are working just fine. All of the evidence IMO suggests this breaks as a result of the upgrade to the newer jenkins core.

            Show
            piratejohnny Jon B added a comment - - edited Mark Waite I am now running "Git plugin 3.9.0" with Jenkins 2.130 and things are working just fine. All of the evidence IMO suggests this breaks as a result of the upgrade to the newer jenkins core.
            Hide
            piratejohnny Jon B added a comment - - edited

            I have marked this as a blocker because it is not viable for us to upgrade Jenkins anymore if it cannot support pinned (tagged) versions of our shared library. I would assume this will also be the case with a large percentage of other users.

            Show
            piratejohnny Jon B added a comment - - edited I have marked this as a blocker because it is not viable for us to upgrade Jenkins anymore if it cannot support pinned (tagged) versions of our shared library. I would assume this will also be the case with a large percentage of other users.
            Hide
            svanoort Sam Van Oort added a comment -

            Oleg Nenashev Mark Waite Can you take another look at this one? If it is indeed a core regression as suggested by the evidence above, we probably will want to resolve this one quickly.

            Show
            svanoort Sam Van Oort added a comment - Oleg Nenashev Mark Waite Can you take another look at this one? If it is indeed a core regression as suggested by the evidence above, we probably will want to resolve this one quickly.
            Hide
            markewaite Mark Waite added a comment -

            Sam Van Oort I won't have time to investigate this further until the weekend at the earliest. I assume you were looking for someone to duplicate the problem as described by the original reporter in order to confirm that the critical change which shows the problem is the update from 2.130 to 2.133.

            Jon B are you running Jenkins from a Docker image? If so, are you running from the Alpine Linux docker image?

            The Jenkins base Alpine image switched to Alpine 3.8 recently. That switched the OpenSSH version provided with that Docker image from a prior OpenSSH to OpenSSH 7.7. OpenSSH 7.7 made an intentional change in behavior which broke the Jenkins git client plugin as described in JENKINS-50573. It is remotely possible that this might be another case of the OpenSSH 7.7 change impacting a use case I had not detected previously.

            Show
            markewaite Mark Waite added a comment - Sam Van Oort I won't have time to investigate this further until the weekend at the earliest. I assume you were looking for someone to duplicate the problem as described by the original reporter in order to confirm that the critical change which shows the problem is the update from 2.130 to 2.133. Jon B are you running Jenkins from a Docker image? If so, are you running from the Alpine Linux docker image? The Jenkins base Alpine image switched to Alpine 3.8 recently. That switched the OpenSSH version provided with that Docker image from a prior OpenSSH to OpenSSH 7.7. OpenSSH 7.7 made an intentional change in behavior which broke the Jenkins git client plugin as described in JENKINS-50573 . It is remotely possible that this might be another case of the OpenSSH 7.7 change impacting a use case I had not detected previously.
            Hide
            piratejohnny Jon B added a comment -

            Mark Waite Indeed I am running Jenkins via the alpine docker image.

            Show
            piratejohnny Jon B added a comment - Mark Waite Indeed I am running Jenkins via the alpine docker image.
            Hide
            markewaite Mark Waite added a comment -

            Jon B could you download the git client plugin 2.7.3 pre-release to check if it resolves the issue for you? If so, then this is not a core regression but a duplicate of JENKINS-50573.

            Show
            markewaite Mark Waite added a comment - Jon B could you download the git client plugin 2.7.3 pre-release to check if it resolves the issue for you? If so, then this is not a core regression but a duplicate of JENKINS-50573 .
            Hide
            markewaite Mark Waite added a comment -

            Included in git client plugin 2.7.3 and git client plugin 3.0.0-beta4 released 24 July 2018.

            Show
            markewaite Mark Waite added a comment - Included in git client plugin 2.7.3 and git client plugin 3.0.0-beta4 released 24 July 2018.
            Hide
            piratejohnny Jon B added a comment -

            git client plugin 2.7.3 seems to resolve the issue under Jenkins 2.133 for my case

            Show
            piratejohnny Jon B added a comment - git client plugin 2.7.3 seems to resolve the issue under Jenkins 2.133 for my case

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              piratejohnny Jon B
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: