- Configure the
- Use Git submodules in CI/CD jobs
Use Git submodules to keep a Git repository as a subdirectory of another Git repository. You can clone another repository into your project and keep your commits separate.
When you use Git submodules, your project should have a file named
You might need to modify it to work in a GitLab CI/CD job.
For example, your
.gitmodules configuration might look like the following if:
- Your project is located at
- Your project depends on
https://gitlab.com/group/project, which you want to include as a submodule.
- You check out your sources with an SSH address like
[submodule "project"] path = project url = ../../group/project.git
When your submodule is on the same GitLab server, you should use relative URLs in
.gitmodules file. Then you can clone with HTTPS in all your CI/CD jobs. You
can also use SSH for all your local checkouts.
The above configuration instructs Git to automatically deduce the URL to use when cloning sources. Git uses the same configuration for both HTTPS and SSH. GitLab CI/CD uses HTTPS for cloning your sources, and you can continue to use SSH to clone locally.
For submodules not located on the same GitLab server, use the full URL:
[submodule "project-x"] path = project-x url = https://gitserver.com/group/project-x.git
To make submodules work correctly in CI/CD jobs:
- Make sure you use relative URLs for submodules located in the same GitLab server.
You can set the
GIT_SUBMODULE_STRATEGYvariable to either
recursiveto tell the runner to fetch your submodules before the job:
variables: GIT_SUBMODULE_STRATEGY: recursive
You can provide additional flags to control advanced checkout behavior using
variables: GIT_SUBMODULE_STRATEGY: recursive GIT_SUBMODULE_UPDATE_FLAGS: --jobs 4
.gitmodules file might be hard to find because it is usually a hidden file.
You can check documentation for your specific OS to learn how to find and display
If there is no
.gitmodules file, it’s possible the submodule settings are in a