Deploy-FinOpsHub throws "Cannot bind argument to parameter 'Path' because it is null" when ran from Azure Devops agent
đ Problem
Deploy-FinOpsHub throws the error "Cannot bind argument to parameter 'Path' because it is null" when ran in an Azure Devops pipeline. I think this is caused by the $env:temp call the function makes which Azure Devops agents seem to have an issue with.
đŖ Repro steps
- Create an
AzurePowershell@5Azure Devops task that installs and imports theFinOpsToolkitpwsh module - Add a
Deploy-FinOpsHubcall to the script - See the error
đ¤ Expected
Should attempt to resolve a different path if $env:temp returns $null.
âšī¸ Additional context
Azure Devops task I am using:
- task: AzurePowerShell@5
displayName: 'Deploy TSC FinOps Hub'
inputs:
azureSubscription: $(Subscription)
pwsh: true
azurePowershellVersion: LatestVersion
ScriptType: 'InlineScript'
Inline: |
Write-Output "Installing FinOps Toolkit pwsh module"
Install-Module -Name FinOpsToolkit -Force -Confirm:$false
Import-Module -Name FinOpsToolkit
$version = "${{ parameters.Version }}"
$name = "$(ResourcesNames)"
$resourceGroup = "$(ResourceGroup)"
Deploy-FinOpsHub `
-Name $name `
-ResourceGroup $resourceGroup `
-Location "eastus" `
-Preview:$true `
-Version $version
Write-Output "Deployment complete"
My current workaround is to add the following at the beginning of the inline script:
[Environment]::SetEnvironmentVariable("temp", "/home/vsts/work/_temp/")
đââī¸ Ask for the community
Let me know if others can reproduce this, especially with GitHub Actions whose runners images are built from the same Dockerfiles as the Azure Devops agents.
We could use your help:
- Please vote this issue up (đ) to prioritize it.
- Leave comments to help us solidify the vision.
@erose96 Deploy-FinOpsHub downloads the specified release from GitHub, which is why it's using $env:temp. According to Copilot, this should be supported đ¤ That said, we could add a property to allow specifying a temp folder using something like $(Agent.TempDirectory). Would that work?
Another option could be to hardcode the template in the PowerShell module. This might work for the latest release, but I don't think we'd want to do that for historical releases. Just a thought.
Tracking this as a feature request since the "bug" is arguably in how PowerShell works in ADO. Please đ vote this up to help prioritize it. I added one to the original issue to get it started. We evaluate the top 10 đ votes each month for inclusion in the next release.