jenkinsci
[JENKINS-70010] SCM 'hudson.scm.NullSCM' is not of type GitSCM
In my scripted multibranch pipeline (using GitLab branch source) I use something like
node(label: 'builder') { checkout scm ... } node(label: 'test') { dir('src') { checkout scm } ... }
Sometimes, the second checkout does not work because
[GitCheckoutListener] SCM 'hudson.scm.NullSCM' is not of type GitSCM
No error is thrown, tough. The build continues and fails later because there are no files in "src". This happens only very occasionally, simply re-running the pipeline will work in most cases.
Any clue how "scm" can become a NullSCM during the build?
Originally reported by 
gordin, imported from: SCM 'hudson.scm.NullSCM' is not of type GitSCM
- status: Open
- priority: Critical
- component(s): git-forensics-plugin, git-plugin, gitlab-branch-source-plugin, pipeline
- resolution: Unresolved
- votes: 0
- watchers: 4
- imported: 2025-12-02
Raw content of original issue
In my scripted multibranch pipeline (using GitLab branch source) I use something like
node(label: 'builder') { checkout scm ... } node(label: 'test') { dir('src') { checkout scm } ... }Sometimes, the second checkout does not work because
[GitCheckoutListener] SCM 'hudson.scm.NullSCM' is not of type GitSCMNo error is thrown, tough. The build continues and fails later because there are no files in "src". This happens only very occasionally, simply re-running the pipeline will work in most cases.
Any clue how "scm" can become a NullSCM during the build?
environment
Jenkins 2.346.1<br/>
GitLab Branch Source Version 630.v04ca_c57fa_880 <br/>
Git Version 4.11.3 <br/>
Git client Version 3.11.0
markewaite:
- Original comment link
Raw content of original comment:
No idea. I have a few jobs that use multiple agents for checkout and have not seen that issue. Most of mine are parallel jobs
No idea. I have a few jobs that use multiple agents for checkout and have not seen that issue. Most of mine are parallel jobs
gordin:
- Original comment link
Raw content of original comment:
We still hit this issue in about 0,1% of our builds. Actually, the second checkout has nothing to do with this issue. Only, when there is a build with two (or more) "checkout" steps the error becomes obvious because the checkout fails. Without a second "checkout" the build will run just fine until the end as long as nothing tries to access "scm".
As a side effect, with multibranch pipelines using the GitLab branch source plugin the final SUCCESS notification to GitLab will not be send, though (I haven't had a look into the code, but I suspect that with the NullSCM there will be no lookup which "parent" the scm is using or something like this. I do not know the mechanism behind the "notify")
I added a
try { ... } finally { echo "SCM: ${scm}" }
to all of our pipelines in order to be able to see how often this issues occurs by running
JENKINS_HOME/jobs/$ grep --include="log" -r "SCM:.*NullSCM" .
on the server. As I said, this affects about 0,1% of our builds.
We still hit this issue in about 0,1% of our builds. Actually, the second checkout has nothing to do with this issue. Only, when there is a build with two (or more) "checkout" steps the error becomes obvious because the checkout fails. Without a second "checkout" the build will run just fine until the end as long as nothing tries to access "scm".
As a side effect, with multibranch pipelines using the GitLab branch source plugin the final SUCCESS notification to GitLab will not be send, though (I haven't had a look into the code, but I suspect that with the NullSCM there will be no lookup which "parent" the scm is using or something like this. I do not know the mechanism behind the "notify")
I added a
try { ... } finally { echo "SCM: ${scm}" }
to all of our pipelines in order to be able to see how often this issues occurs by running
JENKINS_HOME/jobs/$ grep --include="log" -r "SCM:.*NullSCM" .
on the server. As I said, this affects about 0,1% of our builds.
mdelaney:
- Original comment link
Raw content of original comment:
I'm seeing this issue as well, but in declarative jobs with no explicit checkouts. The jobs do have multiple checkouts as we do have a shared library and the declarative scm checkout but nothing where we're calling `checkout scm` or `git` explicitly; like the examples above.
[Pipeline] { [Pipeline] stage [Pipeline] { (Declarative: Checkout SCM) [Pipeline] checkout [GitCheckoutListener] SCM 'hudson.scm.NullSCM' is not of type GitSCM [Pipeline] }Much like gordin, this doesn't happen very often but it does happen.
I'm seeing this issue as well, but in declarative jobs with no explicit checkouts. The jobs do have multiple checkouts as we do have a shared library and the declarative scm checkout but nothing where we're calling `checkout scm` or `git` explicitly; like the examples above.
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Checkout SCM)
[Pipeline] checkout
[GitCheckoutListener] SCM 'hudson.scm.NullSCM' is not of type GitSCM
[Pipeline] }
Much like gordin, this doesn't happen very often but it does happen.
markewaite:
- Original comment link
Raw content of original comment:
The GitCheckoutListener is from the git forensics plugin per the source code. That doesn't help with answering the question "Why does it report that message?".
The GitCheckoutListener is from the git forensics plugin per the source code. That doesn't help with answering the question "Why does it report that message?".
drulli:
- Original comment link
Raw content of original comment:
The output of "[GitCheckoutListener] SCM 'hudson.scm.NullSCM' is not of type GitSCM" is from the git-forensics plugin. It should not change the behavior of checkouts. It just shows that at the time of the invocation not valid SCM is available to record the commits.
The output of "[GitCheckoutListener] SCM 'hudson.scm.NullSCM' is not of type GitSCM" is from the git-forensics plugin. It should not change the behavior of checkouts. It just shows that at the time of the invocation not valid SCM is available to record the commits.