-
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 - 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! 
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.