-
Bug
-
Resolution: Fixed
-
Blocker
-
None
-
2.133 alpine (https://hub.docker.com/r/jenkins/jenkins/tags/)
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.
- relates to
-
-
- Closed
-
[JENKINS-52678] Shared libraries stopped loading with git tags. They only now work when I reference a git branch name
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.
markewaite 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.
Jon B
added a comment - - edited markewaite 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. 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.
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. 
Sam Van Oort
added a comment - oleg_nenashev markewaite 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.
Sam Van Oort
added a comment - oleg_nenashev markewaite 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. svanoort 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.
piratejohnny 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.
Jon B
added a comment - markewaite Indeed I am running Jenkins via the alpine docker image. piratejohnny 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.
Included in git client plugin 2.7.3 and git client plugin 3.0.0-beta4 released 24 July 2018.
Confirming that when we downgrade to 2.130, the original working behavior is restored.