7

A repo ("website") has a submodule ("template"). The submodule is referenced inside a directory of the repo. The goal is to use an Azure DevOps pipeline to build the repo and submodule together. However, the Azure DevOps build throws the following errors:

  • fatal: No url found for submodule path '<repo directory AKA "website">/<submodule directory AKA "template">' in .gitmodules
  • [error]Git submodule update failed with exit code: 128

Depending on adjustments to the .gitmodule file, this error is also thrown:

  • fatal: no submodule mapping found in .gitmodules for path '<repo directory AKA "website">/<submodule directory AKA "template">'.

This question is similar to others asked on Stack Overflow, but the difference is that the default initial step in Azure DevOps builds is to check out files in the branch. So scripts (like git rm --cached <pathtomodule>) cannot be run first.

The "website" and "template" repos are in the same Azure DevOps project.

I have tried two ways unsuccessfully. Both are based on Microsoft documentation. This is because it's unclear to me whether a submodule from the same project can be included in a repo without providing explicit credentials.

  1. Via the UI:

    • "Clean options": "All build directories"
    • "Checkout submodules": True
    • Branch includes a .gitmodule file: True
  2. By git command in a PowerShell task:

Tried variations of both:

$AUTH=$(echo -n ":$(PAT)" | openssl base64 | tr -d '\n')
git -c http.https://dev.azure.com/organization/project/_git/template.extraheader="AUTHORIZATION: basic $AUTH" clone https://dev.azure.com/organization/project/_git/template --no-checkout --branch master

and

git -c http.https://dev.azure.com/organization/project/_git/template.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" submodule update --init --recursive
  • Unsuccessfully tested builds on both on a branch without a .gitmodules file and on a branch with a .gitmodules file.
  • Unsuccessfully tested build tasks in both Bash and (slightly adjusted for) PowerShell.
  • Unsuccessfully tested the various constructions of Azure DevOps repo URLs (like https://organization.visualstudio.com/project/_git/repo, https://$(PAT)@organization.com.visualstudio.com:/project/_git/template, etc.).

Other things tried are variations of the above that include git submodule add in the PowerShell task before the submodule update command, running ls -lR in a Bash task to investigate whether the submodule files downloaded (the build task sometimes indicates success even though the files are missing), and endless variations of the .gitmodules file.

As .gitmodules stands now (unsuccessfully):

[submodule "template"]
    path = <repo directory AKA "website">/<submodule directory AKA "template">
    url = https://dev.azure.com/organization/project/_git/template

Variations include things like:

  • [submodule "<repo directory AKA 'website'>/template"]
  • path = D:\\a\\1\\s\\<repo directory AKA "website">\\<submodule directory AKA "template">
  • path = $env:Build.SourcesDirectory/template
  • url = ../project/_git/template

...and more plus all the various combinations. None are successful.

I am truly stuck and appreciate any insight. Thank you.

hcdocs
  • 1,078
  • 2
  • 18
  • 30
  • According to the search result, the value in [submodule "here"] should be as same as the value of the path. Like https://www.deployhq.com/support/common-repository-errors/no-url-found-for-submodule#submodule-mapping. Or is this optianl. – mbb5079 Dec 30 '19 at 09:42

3 Answers3

12

Not sure if this helps here, but I've struggled with the same error for a submodule that was relocated (moved from /my-submodule to /src/my-submodule in the repository). Doing git rm --force /my-submodule, commit and push to remote resolved the issue for me.

I found that using git submodule status is helpful to locally check whether the submodule state is correct or not. After I tried git rm it stopped reporting the error "fatal: No url found for submodule path 'my-submodule' in .gitmodules"

andyandy
  • 898
  • 8
  • 15
2

FWIW, in my case I encountered this error message while I was cherry-picking a commit that made changes to the .gitmodules file (and which created a merge conflict in it). The solution was to first finish the cherry-pick and afterwards the error message was gone.

Eric Aya
  • 69,473
  • 35
  • 181
  • 253
Raven
  • 2,951
  • 2
  • 26
  • 42
  • I also cherry-picked a commit that changed the .gitmodules file. The changes to that file were _not_ picked! I probably had the same issue when I first tried to rebase. Solution: checkout the .gitmodules file from the original commit, and append to the new commit. – Gauthier Jun 02 '22 at 09:09
0

In my case, Visual Studio was adding the sub-module project to the solution using a relative path like this: "..\MySubModuleProject\MySubmoDuleProject.csproj" even though other projects in the solution were referenced like this: "MyOtherProjects\MyOtherProjects.csproj". It doesn't make sense why this invalid reference worked but removing the ..\ fixed the issue. It worked locally and it fixed the issue in the build pipeline where it couldn't find the project because the solution was wrongly looking for it one directory up.

Here's what my yml steps looked like:

steps:
  - checkout: self
    submodules: true
    persistCredentials: true
    path: ''
    clean: true

Here's my .gitmodules file:

[submodule "MySubModuleProject"]
    path = MySubModuleProject
    url = ../MySubModuleProject
    branch = main

This submodule project is in the same Azure project space as the solution which references it which is why we use ../MySubModuleProject to find it.

GrayDwarf
  • 2,469
  • 2
  • 20
  • 22