-
Bug
-
Resolution: Not A Defect
-
Major
-
Jenkins v2.47
Git Plugin v3.0.3
We have a simple pipeline job. It's defined to use "Pipeline script from SCM" . The SCM is Git and it is pointed at our repo with the credentials set as expected (shared with other pipeline jobs). For branches to build, it is set to `*/master`. Under "Advanced clone behaviors" we have a reference repo set which is local to the machine.
This worked just fine up until about 2 weeks ago. At that point, it stopped automatically triggering and had to be manually triggered (could have been a configuration error made by someone on the team though).
2 days ago I added another branch specifier to this so that it would build if it matched either name as a temporary change. I removed the extra branch after that build was triggered. Since then, all builds have failed with an error like this: `java.lang.NullPointerException: Cannot invoke method replace() on null object` (Full log is attached).
I have no idea why this is now failing and can't correct it. I've tried:
- Removing and recreating the job
- Removing and recreating the job under a different name
- Removing the job, then every mention of the job I could find (using `find`), then recreating.
- Clearing the reference repo and re-cloning in case it was corrupted
- Specifying the full branch name rather than just `*/master`
- Running the git commands specified in the log to make sure they succeed
I'm out of ideas at this point. Our other pipeline jobs using the same reference repo and similar configurations (are set up as scheduled jobs) work fine. We have a multibranch pipeline job that works as expected (building the `master` branch just fine). It's just when I create a pipeline that only runs on that branch that it fails.
[JENKINS-46426] Pipeline fails with null pointer exception
Dale Myers
added a comment - The first one isn't an issue since we don't call anything different between the two jobs. The Jenkinsfile is exactly the same in both, plus it doesn't even get that far. It's on the very initial checkout before the Jenkinsfile is even run.
For the second one, we can't disable the pipeline plugin for obvious reasons. For the third, we don't do anything with views. For the final, again, we don't use anything like this.
These are all just null pointer exceptions. None of them have an even remotely close stack to what we are seeing.
We don't actually get as far as running our pipeline. The very first line of my Jenkinsfile is a `println` and it doesn't get output as it's still handing the git stuff.
Dale Myers
added a comment - The first one isn't an issue since we don't call anything different between the two jobs. The Jenkinsfile is exactly the same in both, plus it doesn't even get that far. It's on the very initial checkout before the Jenkinsfile is even run.
For the second one, we can't disable the pipeline plugin for obvious reasons. For the third, we don't do anything with views. For the final, again, we don't use anything like this.
These are all just null pointer exceptions. None of them have an even remotely close stack to what we are seeing.
We don't actually get as far as running our pipeline. The very first line of my Jenkinsfile is a `println` and it doesn't get output as it's still handing the git stuff. dalemy I've looked at the stack trace, and the git plugin is not involved anywhere in the stack trace. It isn't doing any git work in the chain that is causing the null pointer exception.
The stack trace excerpt:
java.lang.NullPointerException: Cannot invoke method replace() on null object at org.codehaus.groovy.runtime.NullObject.invokeMethod(NullObject.java:91) at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:48) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48) at org.codehaus.groovy.runtime.callsite.NullCallSite.call(NullCallSite.java:35) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113) at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:151) at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:146) at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.methodCall(SandboxInvoker.java:16) at WorkflowScript.run(WorkflowScript:22) at ___cps.transform___(Native Method)
Has one of the folders containing the failing job recently had a global pipeline library added to it?
Each of those tickets involves PogoMetaClassSite. I don't know why you're seeing that null pointer exception, but unless you have a different stack trace, it does not seem to be the git related. We may need to pass this bug to one of the pipeline plugins
Dale Myers
added a comment - >Has one of the folders containing the failing job recently had a global pipeline library added to it?
Not 100% sure what you mean by that, but we've made no changes to any jobs recently with the exception of the addition and subsequent removal of the branch I mentioned above.
Dale Myers
added a comment - >Has one of the folders containing the failing job recently had a global pipeline library added to it?
Not 100% sure what you mean by that, but we've made no changes to any jobs recently with the exception of the addition and subsequent removal of the branch I mentioned above. Pipeline libraries can be defined which are loaded each time a pipeline is executed. They provide reusable components for all pipeline jobs in the context where they are defined. Pipeline library loading is defined at the system level in the "Manage Jenkins", "Configure System", "Global Pipeline Libraries" section.
Pipeline library loading can also be defined in a folder, if your jobs are stored in a folder.
In my environment (as an example), I have a pipeline library that I use for all regression tests. It is loaded from the folder that holds all my regression tests. I use a different pipeline library for plugin development tests. It is loaded from the folders that host my plugin development work.
If you have a pipeline library being loaded, and it contains an error, that might cause those types of surprises.
Dale Myers
added a comment - Nope. No global pipeline libraries. I've added pipeline as one of the projects, and have modified the short description to not that pipeline is what is having the failure, not git clone.
Is the stack trace in the attached file still accurate for the stack trace you're seeing?
Dale Myers
added a comment - Yes, nothing has changed. Dale Myers
added a comment - Ok, just set up a brand new server (running on ubuntu rather than OS X this time) and the exact same error is occurring.
Dale Myers
added a comment - Ok, just set up a brand new server (running on ubuntu rather than OS X this time) and the exact same error is occurring. That would suggest to me that the problem is in the Jenkinsfile on that branch. What types of differences are there between the pipeline definition on the working branch and the non-working branch?
Dale Myers
added a comment - It doesn't get that far though. As I mentioned, there is a println at the very top of the Jenkinsfile and it doesn't get written out.
The Jenkinsfile is the same no matter what branch it's on. The only difference is a single if statement which does this:
spec = ""
{{if (projectName == "outlook-ios-app-store") { spec = "PROD" }}}
{{ else if (branchName == "develop") { spec = "DEV" }}}
{{ else if (branchName == "release") { spec = "STAGE" }}}
{{ else if (branchName == "master") { spec = "DOGFOOD" }}}
{{ else }}{{{ spec = "WIP" }}}
But this isn't new. It's been there for multiple years at this point.
Dale Myers
added a comment - It doesn't get that far though. As I mentioned, there is a println at the very top of the Jenkinsfile and it doesn't get written out.
The Jenkinsfile is the same no matter what branch it's on. The only difference is a single if statement which does this:
spec = ""
{{if (projectName == "outlook-ios-app-store") { spec = "PROD" }}}
{{ else if (branchName == "develop") { spec = "DEV" }}}
{{ else if (branchName == "release") { spec = "STAGE" }}}
{{ else if (branchName == "master") { spec = "DOGFOOD" }}}
{{ else }}{{{ spec = "WIP" }}}
But this isn't new. It's been there for multiple years at this point. You say it doesn't get that far, yet the stack trace seems to show that it is executing pipeline code. Is the stack trace in the attached file no longer an accurate representation of the stack trace you're seeing?
I was wrong. It does get that far. For some reason it's just not spitting out my println. That's why I couldn't figure it out. There was a null value, but based on my debugging it was never getting that far so I never checked it. Thanks for the help!
Dale Myers
added a comment - - edited I was wrong. It does get that far. For some reason it's just not spitting out my println. That's why I couldn't figure it out. There was a null value, but based on my debugging it was never getting that far so I never checked it. Thanks for the help! 
dalemy based on your various attempts to resolve the problem, I suspect it is not a problem with the git plugin, but rather is something more general than the git plugin.
https://github.com/savishy/jenkins-examples/blob/496ad220235ad36793bcb32695645878d7c42f88/README.md suggests that you might have a pipeline library that is not terminated with a return this
JENKINS-39495might have additional information to offer as well.JENKINS-15309(old bug, long resolved) might hint that a view name is unexpectedly empty.JENKINS-14458has a similar method, but does not seem as likely to be related to the case you're seeing.