Today I ran into an error executing a yaml pipeline using Azure DevOps Pipelines. The first step of the job was creating a Resource group, which went fine after creating the Service Connection to my Azure subscription.
When trying to create a KeyVault in this shining new Resource group, using az keyvault create --name --resourcegroup-name a 403 error was returned with not much else to go on:
Google did not return many clues so with little to go on I checked the Service Principal. Of course this was OK, since it was create during the creation of the Service Connection (since this was a PoC I did not bother to create a Service Principle with a nice name up front). It had Contributor rights so that should be enough.
Next thing was a test from PowerShell, using my personal (owner) credentials.
Same very descriptive error…
Last resort: manual creation of a KeyVault using the Azure Portal. This time I received an error which was much more helpful.
After this dialog, I found the policy prohibiting creation quickly. Editing it was not so friendly, searching in those long lists with options is terrible. That solved the problem.
Developing Logic Apps in Azure is quite a nice experience. Using the Azure Portal to design and implement your workflow is easy.
Less pleasurable is creating ARM templates for Logic Apps (perhaps another post another time). Let’s just say now that this requires some manual labor, but the results are very rewarding;)
Using Azure DevOps we are deploying our Azure resources into the ‘Development’ Resourcegroup as the first step in our pipeline. In the case of a Logic App this means overwriting the version you created manually in the Portal. This means that you have to verify the ARM template was correct comparing the current version of the Logic App with the previous one.
Another thing that can happen during this process is an error I ran into today for the second time. It can take some time to figure out what exactly happened so I decided to document this for when it happens again…
If you have linked your Logic App to an instance of Log Analytics, either at creation time or later, you can run into this error at the deploy:
Data sink '/subscriptions/xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/rg-monitoring/providers/Microsoft.OperationalInsights/workspaces/ws-monitoring' is already used in diagnostic setting 'service' for category 'WorkflowRuntime'. Data sinks can't be reused in different settings on the same category for the same resource. (Code: Conflict)
To resolve this error you have to delete the existing diagnostic setting, so ARM can deploy a new one and will not see this setting as duplicate. Subsequent deployments will succeed after this change.
At my team we have been happily using Azure DevOps (formerly known as VSTS, Visual Studio Online) building and releasing our projects into Azure. Yesterday, out of the blue, one of our releases broke. Azure DevOps AzureFileCopy Error. InvalidContentLink, unable to download deployment content from ‘https://…..’
After some inspection this turned out to be a combination of the power of a Software as a Service like Azure Devops, combined with our desire of using the latest and greatest of these applications. We are using V2 of this task, which is in Preview and thus bound to change. In many cases these changes are adding or simplifying features for us developers, but in this case something broke.
In our release pipeline we are using a task called Azure File Copy V2. This task is using azcopy to copy some deployment related stuff into a blob container, in this case a linked ARM template.
The main template, let’s call it azuredeploy.json, is using a path to a linked ARM template. This path is created on the fly using an output parameter of the Azure File Copy task, the outputStorageURI. To this location, a subfolder is added for our linked temlate:
On October 4th a change was done in this task: a trailing slash was added for compatibility with uri function (link to github)
Now, since the release pipeline in Azure DevOps is not as insensitive to duplicate slashes as an OS like Windows, problems rise when this output parameter is combined with our own second part of the template path. The leading slash, which was previously required for the template to work, was now causing a problem…
… and a solution
Luckily I found a workaround quickly because of the open source nature of these Azure pipeline tasks. I introduced a new variable that checks the existence of the trailing slash and adjusts the parameter to get something working again. After that I replaced parameters(‘storageURI) with variables(‘newStorageURI’) in the template. Linked templates don’t have to be updated, they will get the correct URI passed to them by azuredeploy.json.