On my main project, we use Azure DevOps for deployment of our .NEt application. There are build and release agents installed around and about the place, on the relevant servers, and they take card of everything during the build and deployment process.

They also have the capability of updating git repos on each server, to enable us to use RedGate SQL Compare to update databases. We use RedGate SQL Source Control to push all database changes into the repo on our dev environment, so that SQL Compare can create scripts to pull databases in line as we deploy up the chain.

As this Azure DevOps agents that are performing these git operations are running on their own, there needs to be some stored authentication mechanism for git to use when being run by the agent.

Git Credential Manager is an optional extra in the Git for Windows installation procedure. What it does is this:

  • When you first try a git operation such as git fetch from the command line, it pops up an interactive credential prompt.
  • For connections to Azure DevOps, if you enter the credentials you use to connect to your DevOps organisation, it will create a Personal Access Token (PAT) which will be valid for a year.
  • This PAT then enables git to run autonomously from that point forward, without prompting for credentials.

One particular gotcha that we came across recently was actually caused by changes elsewhere in the system... not ideal! When running git commands using the DevOps agent, we were getting this on the command line:

fatal: NotSupportedException encountered.
   The ServicePointManager does not support proxies with the https scheme.

Looking into the git proxy settings, we saw this:


Nothing mentioning https here!

What we found was that the environment variables configured on the server were playing a part here... we found the following environment variables configured:


Notice the first entry there - it's pointing at the proxy using https as the protocol. In fact, this is almost never correct.. Proxies generally work using http, so they can be transparent in the https connection between client and server. This setting had been edited as part of other troubleshooting, and was never removed.

As soon as this was corrected, Git Credential Manager started working again, and all was well!

Leave a Reply

Your email address will not be published. Required fields are marked *