Checkout task with persistCredentials doesn't set credentials for submodule repo(s) when needed

[sphanley]

Agent Version and Platform

2.213.2 on MacOS

Azure DevOps Type and Version

dev.azure.com, organization name can be provided if needed.

What's not working?

I'm using the Azure Pipelines checkout task with submodules: true and fetchDepth: 1. Later in my pipeline, in some cases I need to fetch additional depth, so I've set persistCredentials: true. This causes the following line to be added to the end of my checkout (I've obscured organizational info using curly-brackets):

git config http.https://{organization}@dev.azure.com/{organization}/{project}/_git/{repo}.extraheader "AUTHORIZATION: placeholder_{...}"

However, since this persisted credential is only set for the main repo, and not my submodule repo, I'm getting the following error later when I try to fetch additional depth, with submodules recursed:

Fetching submodule {submodule repository name}
fatal: could not read Password for 'https://{organization}@dev.azure.com': terminal prompts disabled

The desired behavior for this use case would be that if persistCredentials is set to true on a checkout where submodules is also true, the credentials would be persisted for both the top-level repo and also any submodule repositories.

[Roman-Shchukin]

Hi @sphanley thanks for reporting! We are working on more prioritized issues at the moment, but will get back to this one soon.

[bassamhbj]

Hello, is there any update on this issue?
I am facing the same issue and I not able to checkout further modules

[mccolljr]

I believe I am also experiencing this issue... will this be resolved?

[frankhaugen]

Any progress? Is there a simple workaround since this isn't a priority?

[initjsk]

Also experiencing this issue. We are referencing multiple repositories as submodules from one project to another. Something as simple as checking out a repository with submodules should be possible, yes?

@Roman-Shchukin - How is this basic feature not a priority? Do you have a workaround for this?

[praneeth-katta]

Is there a solution or work around for this? this is important to update the main module with the commits of submodule

[frankhaugen]

Who prioritize these issues, and how can I get in touch with them to argue about priorities?

[praneeth-katta]

Only workaround is to clone separately instead of using submodule=true. Even though, this can be easy and dirty solution but can be implemented only if there are one or two submodules. If there are more submodules, it becomes messier

Other option is to use the PAT which can be retrieved from secure files.

[thomas-parikka-milliman]

Has anyone at Microsoft looked at this issue to triage it yet?

[frankhaugen]

Has anyone at Microsoft looked at this issue to triage it yet?

It has been triaged and accepted as a bug, but apparently, it's not important enough

Very frustrating that this has been taking ages, so I'll do a faux pas:

Hey @geekzter you are listed as product manager for Azure Pipelines, (so in desperation I'm tagging you, I know that's not a "nice" thing to do), could we get some eyes on this issue? My employer really needs this feature to work, and judging by the other comments here, this is a huge annoyance for them as well, and it's been some time