Accessing build and release logs in VSTS

VSTS becomes somehow better and better with each release, yet some activities are not so trivial to perform. Don't get me wrong - I'm not talking about hard-to-manage workarounds, rather subtle tricks just to make the job done.

Finding logs

It's fairly easy to download all build/release logs from the GUI - just go to the Logs tab and you will see big Downloads all logs as zip button. But what if I'd like to incorporate them in my build or release process? Unfortunately VSTS doesn't have an artifact source like e.g. TeamCity has, where you can access all information about a build. Fortunately it has a REST API, which happens to be quite helpful there.

REST for the rescue!

When you go to this site, you'll find an overview for the whole API, which VSTS shares. There are two categories - Build and Release - which are the most interesting for us now. Let's look at signatures, which are the most interesting for us:

Get build details
GET https://{instance}/DefaultCollection/{project}/_apis/build/builds/{buildId}/timeline?api-version={version}
Get release details
GET https://{account}{project}/_apis/release/releases/{releaseId}?api-version={version}

To perform those requests, Authorization header is required containing your personal token. You can obtain it by going to https://{your_instance}

Accessing logs

Performing above requests will return detailed info about a build or a release. What is interesting, they will return URLs to the logs related to the specific build or release. Even more - you can access specific step - e.g. output for your custom Powershell script.

Typical URLs for logs:



Although still not without a little overhead, above solution should help you when logs produced by a build or a release are needed. URLs presented may change or differ a little, but remember, that you can get them by requesting build/release info as presented.

Azure Key Vault - making it right

Recently I spent a couple of hours struggling with one of our Azure Key Vaults - its access policies to be more specific. Short story - I was unable to create a new one from the portal, nor access secrets or keys. After exchanging several emails with Microsoft and few calls with their technician, we managed to find both a quick solution and the root of all evil - invalid ARM template.

Key Vaults are somehow fragile resources when it comes to determining who can access them. You can be a "superadmin hero", still if a Key Vault was created in the other tenant or for an object not related with you, you can see it, you can manage it but if it comes to retrieving keys or secrets, you won't be able to do so. It's perfectly fine - it should be as secure as possible - but the way it informs you, that something is wrong, can be described as... well, lacking.

Consider following example:

	"type": "Microsoft.KeyVault/vaults",
	"name": "[parameters('keyVaultName')]",
	"location": "[resourceGroup().location]",
	"apiVersion": "2015-06-01",
	"tags": {
		"displayName": "my-keyvault"
	"properties": {
		"enabledForDeployment": true,
		"enabledForDiskEncryption": true,
		"enabledForTemplateDeployment": true,
		"tenantId": "[parameters('tenantId')]",
		"accessPolicies": [
				"tenantId": "[parameters('tenantId')]",
				"objectId": "[parameters('objectId')]",
				"permissions": {
					"keys": "[parameters('keysPermissions')]",
					"secrets": "[parameters('secretsPermissions')]"
		"sku": {
			"name": "[parameters('vaultSkuName')]",
			"family": "A"

It is possible with ARM to create a key vault, which can be accessed e.g. by a group of admins(by passing correct tenantId and objectId). However, let's say you have made a mistake in those fields. Key vault will still be created with an access policy, but following things will happen also:

  • you won't be able to create a new access policy
  • you won't be able to browse keys
  • you won't be able to browse secrets
  • ARM will still be able to retrieve keys and secrets

Trying to add a new policy will result in "Invalid parameter name 'accessPolicy'" error while managing it with Azure Powershell CLI will give "401 Unauthorized" response. I've seen more descriptive messages in my life TBH.

Microsoft guided me to the solution with their article Change a key vault tenant ID after a subscription move, which describes a solution suitable also if a subscription hasn't been moved and a key vault has just been created(for a invalid tenant or an object). Performing steps from the article helped me in restoring proper access to the key vault and finally led to the proper solution of our issue.