-
Bug
-
Resolution: Won't Fix
-
Minor
-
None
-
Jenkins 2.50
SCM API Plugin 2.1.1
Git plugin 3.1.0
When using GitSCMFile::content() on an object that is symlink the content returned is the path to the symlinked file.
While this might be the intended behavior this might cause problems. For example when using the workflow-multibranch (tested with 2.14) with a Jenkinsfile that is a symlink, this behavior causes the resulting main script to be the path of the symlinked file instead of the file content. E.g. the main script would be "build/Jenkinsfile" (if Jenkinsfile is a link to build/Jenkinsfile)
The behavior is easy reproducible:
- create a multi branch pipeline
- as branch sources use an arbitrary git repository where the Jenkinsfile is a symlink (within the repository)
- run the Job (the job will fail with an exception)
- when looking at the replay - the main script will be the path to the symlinked file
- duplicates
-
-
- Reopened
-
[JENKINS-42882] GitSCMFile::content() doesn't handle symlinks
Bernhard Miklautz
added a comment - omervk I have exactly the same trace except it can't find the property build as the link starts with build.
If this behavior isn't intentional and it worked before with older versions it's definitely a regression because it might cause projects to fail (and the problem isn't obvious from the error messages and hard to track).
Bernhard Miklautz
added a comment - omervk I have exactly the same trace except it can't find the property build as the link starts with build.
If this behavior isn't intentional and it worked before with older versions it's definitely a regression because it might cause projects to fail (and the problem isn't obvious from the error messages and hard to track). I have no indication that this ever worked with any version of the git plugin.
Tiago Nunes
added a comment - I also started experiencing this issue after upgrading to v2 of the plugin. It worked fine with v1.
As a workaround for the time being I replaced the symlink by the actual Jenkinsfile contents. For reference, before finding this issue, I came across this one - JENKINS-42830.
Tiago Nunes
added a comment - I also started experiencing this issue after upgrading to v2 of the plugin. It worked fine with v1.
As a workaround for the time being I replaced the symlink by the actual Jenkinsfile contents. For reference, before finding this issue, I came across this one - JENKINS-42830 . tsbnunes can you describe in more detail what you mean by "v2 of the plugin" and "it worked fine with v1"? I'm not aware of any version of the GitSCMContent API that supported Jenkinsfile as a symbolic link to another location.
Tiago Nunes
added a comment - Hi markewaite. Sorry, I believe my previous comment was not clear and completely accurate.
I just updated a bunch of Jenkins plugins, mostly related to the Pipeline (workflow) and SCM API.
A fair amount of them had dependencies among each other and had warnings referring to this [post|https://jenkins.io/blog/2017/01/17/scm-api-2/,] which mentions the differences of the new SCM API 2, so this issue might actually be caused by a different component and not git-plugin.
Some of the relevant upgrades I did were:
- branch-api: 1.11.1 -> 2.0.8
- scm-api: 1.3 -> 2.1.1
- git: 3.0.1 -> 3.2.0
- workflow-multibranch: 2.9.2 -> 2.14
I have single-branch pipeline jobs with symlinks to Jenkinsfiles that continue working fine, so this seems to only affect multi-branch pipeline jobs.
In the end, it might not be caused by git-plugin itself, but by a regression introduced by one of the others?
I'm afraid I don't know enough about Jenkins plugins internals to easily identify the culprit here.
Tiago Nunes
added a comment - Hi markewaite . Sorry, I believe my previous comment was not clear and completely accurate.
I just updated a bunch of Jenkins plugins, mostly related to the Pipeline (workflow) and SCM API.
A fair amount of them had dependencies among each other and had warnings referring to this [post| https://jenkins.io/blog/2017/01/17/scm-api-2/ ,] which mentions the differences of the new SCM API 2, so this issue might actually be caused by a different component and not git-plugin.
Some of the relevant upgrades I did were:
branch-api: 1.11.1 -> 2.0.8
scm-api: 1.3 -> 2.1.1
git: 3.0.1 -> 3.2.0
workflow-multibranch: 2.9.2 -> 2.14
I have single-branch pipeline jobs with symlinks to Jenkinsfiles that continue working fine, so this seems to only affect multi-branch pipeline jobs.
In the end, it might not be caused by git-plugin itself, but by a regression introduced by one of the others?
I'm afraid I don't know enough about Jenkins plugins internals to easily identify the culprit here. I think this issue depends on workflow-multibranch plugin rather than git plugin. A main cause is JENKINS-33273
We can avoid from the issue with explicit option `Lightweight checkout` in (single) pipeline job.
However, in multibranch pipeline, we cannot specify the option. So I found https://github.com/jenkinsci/workflow-multibranch-plugin/pull/57 and added a following system property below.
-Dorg.jenkinsci.plugins.workflow.multibranch.SCMBinder.USE_HEAVYWEIGHT_CHECKOUT=true
So far, it seems ok in my environment.
Jenkinsfile being a symlink is certainly not a supported configuration.
Based on jglick's comment that Jenkinsfile as a symlink is not a supported configuration, I'm marking this as "Won't Fix"
multibranch pipeline has supported to allow to detect different Jenkinsfile filenames (
https://issues.jenkins-ci.org/browse/JENKINS-34561 ).
That's why I have changed to specify Jenkinsfile path without symbolic link and removed the system property above.
+1 to this issue, just hit it myself.
For reference, when Jenkinsfile is symlinked to ci/build.groovy, this is what I'm seeing: