The runbook will now bring AzureRM.Profile, AzureRM.Automation, AzureRM.Resources up to the latest version before importing other modules. You will need to also set the parameters AutomationAccountName and AutomationResourceGroupName as the logic that automatically discovers the AA account does not work on the early versions of AzureRM.
If the runbook is started without setting the parameters it will terminate with an warning telling you to set the parameters.
After the AzureRM modules are on the latest version you can run the import runbook anew to install the wanted modules.
So I was trying to add owners on AzureAD groups and found that this was not something you currently could do by using the Az-module from the built-in Azure Powershell task. I knew this was supported using the AzureAD modules, though there was no existing way of using this directly in AzDO. I therefor set out on a journey to figure out how to get this done.
I started with learning how the built-in tasks Microsoft has published works. Especially the one found here.
After much testing, what I found to be the biggest hurdle to get over was that I could not get Connect-AzureAD to work with the code targeting the module through the task. It would just error out with not authenticated, and could therefore not run the code.
This took some doing to figure out, but after combining MSAL.PS module and using the token it attains on Connect-AzureAD I finally managed to get it working. This after also realizing that the service connection used for the task, or more correctly the ServicePrincipal in AzureAD also needed to be given the correct access level to the Azure Active Directory Grap api. The example below I only needed to read, but if changes is to be allowed one would need to add the Directory.ReadWrite.All role to the SP.
So Terraform is all the rage at the moment, so why not cash in on some of that action?
So here is the pitch, write IaC with Terraform you should at least go down the path of creating modules and reference them in your code. This is a good move and something we know from previous experience with other languages makes everything more maintainable as entropy tries to run us over.
Though mixing modules and running terraform in a pipeline some new challenges arise. Especially if you want to host the modules in a private repository.
The Microsoft backed tasks for running Terraform in a AzD pipeline needs in it’s init phase to resolve and download all external referenced modules. This is not a problem for the ones that are public, but if you have module in a private repo then this phase will just fail.
So a solution is to host the modules in AzD git and leverage the access token the agent is given when running a pipeline.
Note: Depending on the project structure you might need to give the build account you are running the Terraform pipeline under access to read the repo(s) where you host the terraform modules.
Now all you need is to create a powershell task that runs before Terraform init task and pass in the build access token to the powershell script below. This will use the token to configure git on the agent to use it to access repos where the modules are. If you have your own custom agents, make sure git is installed on all of them for this to work correctly.
Now for the code to set the git context:
So with this done you will want to clean up the context after the terraform init task has run with the following code:
Hope this helps anybody else struggling with this.