As part of my vNext Builds in VSTS I have been publishing my build output to a network share location on my build agent. Today I had a new requirement to make these builds available to other services that were in a different VNet, and did not have access to this share. So, I decided to try to make use of the Azure File Storage offering.
Using the Azure Portal I first created a new File Storage called “builddrops” in an existing storage account that I had. I’m not going to cover the creation of this, but more details can be found here.
Opening the build definition and looking at the Publish Artefact task the output path obviously accepts UNC paths, as this is what I have been using.
However, there is no way to specify the credentials to be used for connecting to this location. The connection will be made using the user account under which the Build Agent is running. This is fine for copying to locations on your internal network where you can authenticate using AD accounts, or duplicated local machine accounts, but not so great when you want to use Azure File Storage where the user credentials are the storage account name and the associated access key. Fortunately there is a workaround for this.
Using the cmdkey.exe tool you can specify the stored credentials to be used for establishing connections. An example would be:
cmdkey /add:<storageaccountname>.file.core.windows.net /user:<storageaccountname> /pass:<storageaccesskey>
However, this will only add stored credentials for the user who is currently logged in . It is unlikely that your build agent service is running under the same user account as you are logged in as – indeed it really should not be. So, you need to add the stored credentials to the relevant service user account. You can do this by making use of the runas command like so:
runas /user:<serviceuseraccount> "cmdkey /add:<storageaccountname>.file.core.windows.net /user:<storageaccountname> /pass:<storageaccesskey>"
You can also invoke a new command prompt running as your build user:
runas /user:<serviceuseraccount> "cmd.exe /k"
Run “whoami” to verify that the user account is as you’d expect. You can then run “cmdkey /list” to validate that the credentials have been cached.
Now you can update your Publish Artefacts path to be the UNC path for your Azure File Storage. Kick-off a build and you should see your build output pushed to your new File Storage location.