There have been a number of bug reports where Multibranch Pipeline jobs wouldn't work properly, with checkout failures; particularly painful: the jobs appear to be working fine right after their creation, but only until Jenkins is restarted.

stephenconnolly kindly pointed out several times that the source element needs to have an id attribute, which is properly set when using the web interface. A job's on-disk configuration would ressemble this:

<org.jenkinsci.plugins.workflow.multibranch.WorkflowMultiBranchProject plugin="workflow-multibranch@2.21">
…
  <sources class="jenkins.branch.MultiBranchProject$BranchSourceList" plugin="branch-api@2.5.4">
    <data>
      <jenkins.branch.BranchSource>
        <source class="jenkins.plugins.git.GitSCMSource" plugin="git@3.12.0">
          <id>f0ca0205-e5ae-48e6-bb6c-46661a8bcc45</id>
          <remote>https://salsa.debian.org/installer-team/apt-setup/</remote>
          <traits>
            <jenkins.plugins.git.traits.BranchDiscoveryTrait/>
          </traits>
        </source>
      </jenkins.branch.BranchSource>
    </data>
    <owner class="org.jenkinsci.plugins.workflow.multibranch.WorkflowMultiBranchProject" reference="../.."/>
</sources>
…
</org.jenkinsci.plugins.workflow.multibranch.WorkflowMultiBranchProject>

Most bug reports were about automating addition of jobs, done through the Groovy console.

The following code excerpt makes it possible to add a Multibranch Pipeline job with a Git source:

import jenkins.branch.*
import jenkins.plugins.git.*
import jenkins.plugins.git.traits.*
import org.jenkinsci.plugins.workflow.multibranch.*

name = "test1"
repo = "https://salsa.debian.org/installer-team/apt-setup/"
WorkflowMultiBranchProject mbp = Jenkins.instance.createProject(WorkflowMultiBranchProject.class, name)
GitSCMSource gitSCMSource = new GitSCMSource(repo)
gitSCMSource.setTraits([new BranchDiscoveryTrait()])
BranchSource branchSource = new BranchSource(gitSCMSource)
mbp.getSourcesList().add(branchSource)

But this results in a missing id attribute when looking at the on-disk configuration…

Reading Stephen's comments in other issues, I tried calling the setId() method, but that triggered an error since the id was said to be already set, so couldn't be set to another value.

That's what I've added a single line to print its current value, right after the object creation:

GitSCMSource gitSCMSource = new GitSCMSource(repo)
println gitSCMSource.id

This indeed prints an ID, and this mere println addition triggers the addition of that id attribute in the newly-generated job's config.xml file!

So it looks to my (non-Java/Jenkins/Groovy-expert) eyes that:

• There might be something fishy going on when the id attribute isn't accessed/printed, leading to an apparently fine job, but only because there's an value that's only in-memory and not written to disk? That would explain why restarting Jenkins triggers the issue: the in-memory value is lost and can't be recovered when reloading from the job's config.xml file?
• Printing the id attribute seems to trigger some side-effect that leads to the attribute being written to disk as required for the Git plugin to function properly.

All of this was originally discovered while preparing a migration for a customer on a fully configured instance, but was trivially reproduced with a bare Jenkins, installed without any plugins at first; where Pipeline and Git were added before performing the additions through the Groovy console. I'm happy to help provide more information, and possibly to test bugfixes.

[Edited to fix highlight/syntax issues because both the visual and text editors are playing tricks on me.]