I am unable to duplicate the problem you're describing.

My attempt to duplicate the problem on Jenkins 2.164.3 with git plugin 3.10.0 on Debian 9 with JDK 8:

1. Create JENKINS-57587 branch in my jenkins-bugs repository
2. Create a pipeline job
3. Configure job to get Pipeline script from SCM using Git
4. Configure git repository https://github.com/MarkEWaite/jenkins-bugs to checkout branch JENKINS-57587
5. Leave Lightweight checkout enabled in the job definition
6. Save the job definition
7. Build now

Can you provide more details on your configuration and how it is different from the configuration I tried?

My test job uses a pipeline shared library.

The source code at the failing location indicates that either the repository was null or the returned ObjectId was null. Neither are expected conditions.

Any further details jblaine?

Mark, I will try to reproduce with Git Plugin 3.10.0. That wasn't available yet when we saw this failure. If it still fails, I will provide more details about our config and the job config but the latter test case is pretty simplistic.

Since 3.10.0 doesn't change anything in this area compared to 3.9.3, I assume you will still be able to duplicate it.

If you can duplicate it, please upload the config.xml of the job definition so that I can compare it to my test job. Also, please describe any areas where the steps you took were different than the steps I took.

I used an ssh protocol Bitbucket URL (git@bitbucket.org:markewaite/jenkins-bugs.git) to clone the Pipeline with git plugin 3.10.0 and git plugin 4.0 pre-release without seeing an NPE. I also used ssh://git@bitbucket.org/markewaite/jenkins-bugs.git to check with git plugin 3.10.0. I'm using an ed235519 ssh credential with the Bitbucket repository. Unfortunately, I still can't duplicate the problem you're seeing.

Well isn't that fun... I came back finally to provide you with more info and ... can no longer reproduce this. I guess this can be closed. Thanks for assisting and trying to solve this with me, Mark.

Thanks for checking again. If you find a way to duplicate it, please reopen it with the details.

I was able to reproduce the issue.

Just use a star "*" as the branch pattern. This will result in a NullPointerException.
Maybe you should add this to the "not supported" checks in the GitSCMFileSystem class:

https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/jenkins/plugins/git/GitSCMFileSystem.java#L255 

And if you're on it:
If you leave the branch field empty or use the default "**" the plugin will complain about an invalid refspec:

java.lang.IllegalArgumentException: Invalid refspec refs/heads/**
 at org.eclipse.jgit.transport.RefSpec.checkValid(RefSpec.java:540)
 at org.eclipse.jgit.transport.RefSpec.<init>(RefSpec.java:192)
 at org.eclipse.jgit.transport.RefSpec.<init>(RefSpec.java:227)
 at jenkins.plugins.git.GitSCMFileSystem$BuilderImpl.build(GitSCMFileSystem.java:345)
 at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:197)
 at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:173)
 at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:115)
 at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:69)
 at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:299)
 at hudson.model.ResourceController.execute(ResourceController.java:97)
 at hudson.model.Executor.run(Executor.java:429)
Finished: FAILURE

Maybe this should be added to the not supported cases too.

Thanks hickstein. It seems counterintuitive to me to use a wildcard for a Pipeline job branch name. That will cause the specific Pipeline job to switch between branches as changes arrive on the individual branches. That creates a changelog in the job which is difficult to understand and leads to the JENKINS-19022 XML bloat problem. The multibranch Pipeline job type is designed to automatically create and destroy jobs for each branch in a repository.

Is there a use case that I've missed for wildcard branch names with a Pipeline job?

That's right. It is very counterintuitive. But for people that are not able to use Multibranch Pipelines (huge git repositories, long build times and seperate workspaces for every branch does not work very well) this is the only option. Thanks for pointing me to the issue. That is one problem we are currently facing.

Nevertheless, throwing a NullPointerException is not very intuitive either. A human readable error message (or just a Fallback to heavyweight checkout) might be a better option in my opinion.

EDIT: We use it in conjunction with Bitbucket Server and the "Webhook to Jenkins for Bitbucket Server" Plugin. We can get a deterministic checkout of the related Jenkinsfile this way.

Thanks! I agree wholeheartedly that it is a bug and it is much worse to throw a null pointer exception than to provide the user a clear message.

See https://github.com/jenkinsci/git-plugin/pull/914 for the pull request that resolves it.

The fix prevents the lightweight checkout by declaring that lightweight checkout does not support a branch named '*'. That is correct, since lightweight checkout uses GitSCMFileSystem and GitSCMFileSystem needs an unambiguous commit.