Jenkins: Deploying Projects from Git with Submodules

Introduction

To some, the word "submodules" strikes fear into the very heart of those developers who dare speak or hear it.

Ok, maybe it isn't that bad: Submodules can be a great way to tie together and deploy your services, especially in a microservices environment.

There are, of course, various quirks to overcome when dealing with them.  One such nuance I want to address in this post is deploying a project with submodules via Jenkins Pipelines (for those who missed it, be sure to check out my introduction to Jenkins Pipelines in my previous post).

The Issue

Whether you allow Blueocean to help manage your pipeline and Jenkinsfile or not, you still need to associate your Jenkins job with the necessary project in Git (the one referencing submodules, in this case).

You would think that adding in the repository's path along with the necessary credentials would be all that is necessary to connect to the project before moving on and configuring the rest of your Jenkins job.

However, sometimes, when you try to run the Jenkins job, you may notice that Jenkins throws an error and fails the build, saying that the job doesn't have sufficient permissions to pull the linked submodules from the main Git project.

Possible Solutions

As it turns out, in some implementations of Git, the credentials used to log in to the parent project doesn't automatically propagate the same credentials to the referenced submodules. It is often the case that we want to use the same credentials to log in to both the main Git project and its submodules.

One possible solution is as follows:

1. Go to "Configure" the Jenkins job.

2. Under "Branch Sources," in the "Git" section, under "Behaviors," click "Add," and then select "Advanced sub-modules behaviors."

3. Enable "Use credentials from default remote of parent repository."

4. Save your changes and try to run the job again.

Often, times this is enough to correct the issue.

Sometimes, however, it isn't.

Another potential solution if your Jenkins job is a Jenkins Pipeline project is to edit your Jenkins file and create/update a "Checkout" stage (you can see how to script this kind of behavior in my previous post).

There is a GitSCM class that is essentially the same one used by the GUI-driven solution above.

So, in your Jenkinsfile, try inserting this in the appropriate place, updating any placeholders as necessary:

checkout(
  [
    $class: 'GitSCM', 
    branches: [
      [
        name: '*/master'
      ]
    ], 
    doGenerateSubmoduleConfigurations: false, 
    extensions: [
      [
        $class: 'SubmoduleOption', 
        disableSubmodules: false, 
        parentCredentials: true, 
        recursiveSubmodules: true, 
        reference: '', 
        trackingSubmodules: false
      ]
    ], 
    submoduleCfg: [], 
    userRemoteConfigs: [
      [
        credentialsId: '<Jenkins Credential Id for this reop>', 
        url: 'git@gitlab.com:path/to/project.git'
      ]
    ]
  ]
)

The important parts to note:

• parentCredentials is what we're primarily after here. Make sure this is set to true!
• If your submodules also reference submodules, make sure that recursiveSubmodules  is also set to true.
• Be sure to set the branch name to pull from whichever branch it is you wish to deploy from.

• Under "userRemoteConfigs," this is where you'll reference the credentials used to connect to Git. If you're using Blueocean, this was likely taken care of for you already and should appear in the Jenkinsfile. If not, be sure to setup credentials in Jenkins (usually found in the left-hand navigation towards the bottom) and reference them here.

Re-run the Jenkins job with the updated Jenkinsfile and see if your permission woes have gone away.

Conclusion

Submodules can be a bit tricky to deal with when you're first making use of them, especially when you see counter-intuitive behavior like this. Hopefully one of the solutions in this post will help get you past this particular headache so you can move on with your deployment!