Azure-devops-docs: Submodule checkout fails if no username is specified

Created on 30 Oct 2018  Â·  11Comments  Â·  Source: MicrosoftDocs/azure-devops-docs

I get following error if the submodule which is a repository of the same project then the main project.

fatal: could not read Username for 'https://dev.azure.com': terminal prompts disabled
fatal: clone of 'https://dev.azure.com/company-name/project-name/submodule-repository-name'

System.InvalidOperationException: Git submodule update failed with exit code: 1
at Agent.Plugins.Repository.GitSourceProvider.GetSourceAsync(AgentTaskPluginExecutionContext executionContext, RepositoryResource repository, CancellationToken cancellationToken)
at Agent.Plugins.Repository.CheckoutTask.RunAsync(AgentTaskPluginExecutionContext executionContext, CancellationToken token)
at Agent.PluginHost.Program.Main(String[] args)

The submodule url is in the format:

https://dev.azure.com/company-name/project-name/submodule-repository-name

As workaround the following url works:

https://[email protected]/company-name/project-name/submodule-repository-name

But the documentation says that the submodule url should be:

https://dev.azure.com/fabrikamfiber/_git/ConsoleApp

Is there a possibility to omit the username in the submodule url?


Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

Pri2 cba devops-cictech devopprod support-request

Most helpful comment

@Hobart2967 I found a solution that works for me:
you have to use the URL that you get on dev.azure.com when you click on clone on a project. I have copied the url from the address bar which is not working

it should be of the following form:

https://owner@dev.azure.com/owner/company/_git/project

All 11 comments

I was able to get this working by using relative paths. Note, the documentation does state that the relative path must be inside the same project as the parent git repo. I used this from a private build agent, so even though the path is relative, it still correctly finds and checks out the repo from azure devops repos.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Keep-alive

Just had the same issue with a git submodule in our repo. Last successful build was May 20th 2019, then simply pushing the same commit to a different branch broke the build.

Same issues here. Can someone take a look at that? It is a critical feature for us and it takes a lot of time figuring out where the issue is.

We had the same issue.
I found a workaround by editing the .gitmodules files where i changed the url parameter to point to the visualstudio.com url.
Url = https://yourcompany.visualstudio.com/YourCompany/_git/YourProject

Yes, but that is a workaround. Since MS is pushing us to use the new URL (dev.azure.com) I would expect a period of time where both URLs will work. Current status is holding us from migration from old URLs to a new ones. Will there be a possibility that it will work on both URLs at the same time or should we count with that and add this requirement to a migration plan?

bump, workaround not working anymore. But anyhow, when using linux clients, the username should not be present in the url, otherwise, alternate credentials wont work

@Hobart2967 I found a solution that works for me:
you have to use the URL that you get on dev.azure.com when you click on clone on a project. I have copied the url from the address bar which is not working

it should be of the following form:

https://owner@dev.azure.com/owner/company/_git/project

@michaelmairegger I have a submodule where the repo is from a private azure devops. The git submodule update is using the new format of the repo url. And still getting the same issue where azure pipeline agents are unable to read username. I tried the "Checkout Submodule" option which results in the same error. Please provide a solution. This is holding us back.

@michaelmairegger 's solution worked! Thanks Michael!

Was this page helpful?
0 / 5 - 0 ratings