Azure-pipelines-tasks: Azure File Copy Task Fails with Azure PS Version 1.4.0

Created on 8 May 2016  路  21Comments  路  Source: microsoft/azure-pipelines-tasks

When a build agent has Azure PS Cmdlets version 1.4.0 installed the Azure File Copy Task will fail with the following error:

Cannot bind argument to parameter 'storageKey' because it is an empty string.

The previous version of Azure PS Cmdlets 1.3.2 works fine.


Raw Task Logs with Azure PS 1.4.0

2016-05-08T06:24:48.9801943Z Executing the powershell script: C:\Agent\tasks\AzureFileCopy\1.0.52\AzureFileCopy.ps1
2016-05-08T06:24:49.1676994Z Looking for Azure PowerShell module at C:\Program Files (x86)\Microsoft SDKs\Azure\PowerShell\ServiceManagement\Azure\Azure.psd1
2016-05-08T06:24:49.9958542Z AzurePSCmdletsVersion= 1.4.0
2016-05-08T06:24:50.0583559Z Get-ServiceEndpoint -Name ******** -Context Microsoft.TeamFoundation.DistributedTask.Agent.Worker.Common.TaskContext
2016-05-08T06:24:50.0739805Z tenantId= ********
2016-05-08T06:24:50.0739805Z azureSubscriptionId= ********
2016-05-08T06:24:50.0739805Z azureSubscriptionName= ********
2016-05-08T06:24:50.2146097Z Add-AzureRMAccount -ServicePrincipal -Tenant ******** -Credential System.Management.Automation.PSCredential
2016-05-08T06:24:50.7982308Z Select-AzureRMSubscription -SubscriptionId ******** -tenantId ********
2016-05-08T06:24:51.0235517Z ##[debug]Loading AzureUtilityGTE1.1.0.ps1
2016-05-08T06:24:57.3994077Z ##[error]Cannot bind argument to parameter 'storageKey' because it is an empty string.

Raw Task Logs with Azure PS 1.3.2

2016-05-08T06:56:10.0177511Z Executing the powershell script: C:\Agent\tasks\AzureFileCopy\1.0.52\AzureFileCopy.ps1
2016-05-08T06:56:10.2052547Z Looking for Azure PowerShell module at C:\Program Files (x86)\Microsoft SDKs\Azure\PowerShell\ServiceManagement\Azure\Azure.psd1
2016-05-08T06:56:11.0646512Z AzurePSCmdletsVersion= 1.3.2
2016-05-08T06:56:11.1271528Z Get-ServiceEndpoint -Name ******** -Context Microsoft.TeamFoundation.DistributedTask.Agent.Worker.Common.TaskContext
2016-05-08T06:56:11.1427777Z tenantId= ********
2016-05-08T06:56:11.1427777Z azureSubscriptionId= ********
2016-05-08T06:56:11.1427777Z azureSubscriptionName= ********
2016-05-08T06:56:11.2834062Z Add-AzureRMAccount -ServicePrincipal -Tenant ******** -Credential System.Management.Automation.PSCredential
2016-05-08T06:56:11.7897892Z Select-AzureRMSubscription -SubscriptionId ******** -tenantId ********
2016-05-08T06:56:11.9616688Z ##[debug]Loading AzureUtilityGTE1.1.0.ps1
2016-05-08T06:56:14.5176791Z Uploading files from source path: 'D:\Agent\Work\326ad65b5\********.Backend.CI\Backend\artifacts\package.zip' to storage account: '********' in container: '********' with blobprefix: 'deployments/********'
2016-05-08T06:56:16.7210196Z Uploaded files successfully from source path: 'D:\Agent\Work\326ad65b5\********.Backend.CI\Backend\artifacts\package.zip' to storage account: '********' in container: '********' with blobprefix: 'deployments/********'
Release deployment

Most helpful comment

While waiting for the fix, we've manually patched AzureFileCopy\1.0.54\AzureUtilityGTE1.0.ps1 as follows:

function Get-AzureStorageKeyFromARM
{
    param([string]$storageAccountName)

    if (-not [string]::IsNullOrEmpty($storageAccountName))
    {
        # get azure storage account resource group name
        $azureResourceGroupName = Get-AzureStorageAccountResourceGroupName -storageAccountName $storageAccountName

        Write-Verbose "[Azure Call]Retrieving storage key for the storage account: $storageAccount in resource group: $azureResourceGroupName"
        $storageKeyDetails = Get-AzureRMStorageAccountKey -ResourceGroupName $azureResourceGroupName -Name $storageAccountName -ErrorAction Stop
        $storageKey = $storageKeyDetails[0].Value
        Write-Verbose "[Azure Call]Retrieved storage key successfully for the storage account: $storageAccount in resource group: $azureResourceGroupName"

        return $storageKey
    }
}

The line:

        $storageKey = $storageKeyDetails[0].Value

is what has been changed.

All 21 comments

Azure File Copy task has not been signed off yet with Azure SDK 1.4.0. You can refer the "Supported Azure and Azure RM module versions" section in ReadME https://github.com/Microsoft/vsts-tasks/blob/master/Tasks/AzureFileCopy/README.md

@kmkumaran Do you have an idea when it may be ready? We are very keen to move to Azure PS 1.4.0 to fix https://github.com/Azure/azure-powershell/issues/2120

We have the sing-off planned sometime next sprint. I will post back to this thread once we have it ready.

Do you have any news about this issue?

While waiting for the fix, we've manually patched AzureFileCopy\1.0.54\AzureUtilityGTE1.0.ps1 as follows:

function Get-AzureStorageKeyFromARM
{
    param([string]$storageAccountName)

    if (-not [string]::IsNullOrEmpty($storageAccountName))
    {
        # get azure storage account resource group name
        $azureResourceGroupName = Get-AzureStorageAccountResourceGroupName -storageAccountName $storageAccountName

        Write-Verbose "[Azure Call]Retrieving storage key for the storage account: $storageAccount in resource group: $azureResourceGroupName"
        $storageKeyDetails = Get-AzureRMStorageAccountKey -ResourceGroupName $azureResourceGroupName -Name $storageAccountName -ErrorAction Stop
        $storageKey = $storageKeyDetails[0].Value
        Write-Verbose "[Azure Call]Retrieved storage key successfully for the storage account: $storageAccount in resource group: $azureResourceGroupName"

        return $storageKey
    }
}

The line:

        $storageKey = $storageKeyDetails[0].Value

is what has been changed.

@antmeehan I have no clue how you figured that out, but seems to have worked for me too...

This fix also worked for me but my ps1 file was located in tasks\AzureFileCopy\1.0.62 (more recent version I presume), so I guess the reported problem is not fixed yet.

Can someone tell me how the tasks that are present on the agent folder are updated and when? I don't see them in the .zip agent that is downloaded from VSTS.

@nelsonmorais The agent must ping VSTS periodically and download the latest agent tasks, or when starting a task the version number of the task might be specified (and it downloads if it doesn't have them).

Luckily it doesn't do a checksum or anything to make sure the source hasn't been modified :)

[I don't work for MS, I'm just guessing based on observed behaviour]

@antmeehan Thank you for your comment.
@kmkumaran Maybe someone from MS could also clarify how the process works, and also give more information when this problem will be fixed

I got this problem again, now with the task version 1.0.69
@kmkumaran Any plans to have this fixed?

I also have this issue now with 1.0.69. Surely this shouldn't be closed...

Latest Supported Azure Module version is 1.3.2. [https://github.com/Microsoft/vsts-tasks/blob/master/Tasks/AzureFileCopy/README.md#supported-azure-and-azurerm-module-versions]
You can download the Azure Module version 1.3.2 for fix. This bug will be resolved in upcoming sprint.

@vincentdass Do you have any date to when this will be available? When will 2.x be supported?

@stack111 , It's currently in progress. Will be updating the status soon.

I don't fully get this, were not using any manual commands, we are running inside VSTS builds thus and deploying directly to Azure, but all of a sudden our deployment task has failed with this nonsensical error. We have been using the same build definitions for months without change, but just today we are receiving:

Cannot bind argument to parameter 'files' because it is an empty string.

Id like to know (clearly and simply) what has changed in Azure for this to happen. Our Azure admin says nothing has changed. We are only deploying from VSTS on a hook when a repo is merged. So nothing to do with build scripts etc:

Anyone can offer a plain English solution?

this the last I remember on this thread since it is so old. I believe these VSTS tasks depend on Azure Poweshell and in our agents some of them had higher version(s) of AzurePs installed and the task was not compatible with the higher version.

I hope that helps provide a starting point to investigate.

Hi @stevematdavies , please send the debug logs to [email protected] . Also, are you using a Hosted Agent? If yes, then which Pool? "Hosted" or "Hosted VS2017" . If not, then can you tell what is the version of Azure PowerShell on your private agent.

After upgrading AzureRM from v5.7.0 to v6.8.1 we ran into this very problem with Azure File copy task in our TFS. Issue can be fixing by merging following line in the very same file from v2 of the task:
$azureStorageAccountResourceDetails = (Get-AzureRMResource -ErrorAction Stop) | Where-Object { ($_.ResourceType -eq $ARMStorageAccountResourceType) -and ($_.Name -eq $storageAccountName)}
https://github.com/Microsoft/vsts-tasks/blob/master/Tasks/AzureFileCopyV2/AzureUtilityGTE1.0.ps1

@vincentdass This shouldn't be closed - still an issue in Azure DevOps pipelines as @mkusmiy alluded to.

A fix that worked for me is by modifying line 27 of AzureUtilityGTE1.0.ps1 (@mkusmiy , you had a small typo in your snippet above, missing the "_" in $.ResourceType and $.Name)

from
$azureStorageAccountResourceDetails = (Get-AzureRMResource -ErrorAction Stop) | Where-Object { ($_.ResourceType -eq $ARMStorageAccountResourceType) -and ($_.ResourceName -eq $storageAccountName)}

to
$azureStorageAccountResourceDetails = (Get-AzureRMResource -ErrorAction Stop) | Where-Object { ($_.ResourceType -eq $ARMStorageAccountResourceType) -and ($_.Name -eq $storageAccountName)}

Edit: V2 of the task (in preview) also worked.

@soccerjoshj07 , Closing the issue as the new Azure File Copy V3 should fix this issue.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

syltaxue picture syltaxue  路  3Comments

yaananth picture yaananth  路  3Comments

timfish picture timfish  路  3Comments

MichaelWhiteCodingForFun picture MichaelWhiteCodingForFun  路  3Comments

gregpakes picture gregpakes  路  3Comments