Azure-pipelines-tasks: AzureFileCopyV4 has modified destination path

[davidmw]

Question, Bug, or Feature?
Type: Bug

Enter Task Name: AzureFileCopyV4

Environment

• Server - Azure Pipelines
  
  
  
  • If using Azure Pipelines, provide the account name, team project name, build definition name/build number:
    
    Account: become-education/Development Release for AccountsCenter-CD > Release-154
  
  

Issue Description

Destination path for file copy into storage account blob is correct on V3 but wrong on V4.

The command captured in the log is:
##[command] & "AzCopy\AzCopy.exe" copy "D:\a\r1\a_AccountsCenter-CI\drop" "https://b3m3accountstest.blob.core.windows.net/`$web" --log-level=INFO --recursive

With V3 the files end up here: https://b3m3accountstest.blob.core.windows.net/$web
With V4 the files end up here: https://b3m3accountstest.blob.core.windows.net/$web/drop

Task logs

tasklog_8.log
tasklog_7.log

[AmrutaKawade]

@davidmw AzureFileCopy4 uses azcopy v10 module vs v7 module in AzureFileCopy3. For task version 4 you can set source as D:\a\r1\a_AccountsCenter-CI\drop\* which will copy contents instead of whole directory

[marksolbergerbjorkerot]

Why has there been a change through commit 0e9c3c69d2e3c7be17b69dd27cb77f44ebf75e9b on Utility.ps1 where the destination path gets a "/" suffixed to it? This makes the copying of files to be made to a VD which is clearly a breaking change and thus rendering our core pipeline functionality to not work as expected.

[AmrutaKawade]

@marksolbergerbjorkerot to make it consistent with V3 of task. VDs were not getting created in V4 of Task https://developercommunity.visualstudio.com/content/problem/1109500/azure-file-copy-task-drops-file-name-when-using-pr.html

[sopelt]

We are facing a similar issue where blob prefixes are handled differently between 4.175.4 and 4.175.4:

As a disclaimer ... we might have been using the task a bit strange/wrong in the first place but nevertheless the behavior changes and our build/release broke.

We had roughly the following settings:

"SourcePath": "$(Build.ArtifactStagingDirectory)/OData/OData.Web.zip",
"BlobPrefix": "$(Build.BuildNumber)/OData.Web.zip",

which previously resulted in

& "AzCopy\AzCopy.exe" copy "D:\a\1\a\OData\OData.Web.zip" "https://xxx.blob.core.windows.net/odata/2020.11.19.1/OData.Web.zip" --log-level=INFO --recursive

and now in

& "AzCopy\AzCopy.exe" copy "D:\a\1\a\OData\OData.Web.zip" "https://xxx.blob.core.windows.net/odata/2020.11.19.1/OData.Web.zip/" --log-level=INFO --recursive

which causes the final blob url to change from

"https://xxx.blob.core.windows.net/odata/2020.11.19.1/OData.Web.zip"

to

"https://xxx.blob.core.windows.net/odata/2020.11.19.1/OData.Web.zip/OData.Web.zip"

[marcowenneker]

(Like @sopelt)
We deploy 'immutable versioned zip files' from a DevOps release pipeline.
e.g. ACC-SomeProductApi-b20201002.4-v1.24.0.1857-d9e95a1.zip
Recent change breaks this.
Currently we get a blob in the form folder/file.zip
ACC-SomeProductApi-b20201002.4-v1.24.0.1857-d9e95a1/SomeProductApi.zip

[AmrutaKawade]

we are reverting this change for now. sorry for inconvenience caused

[AmrutaKawade]

This will get deployed by end of this week. Closing this issue