How does the fallback mechanism of DownloadFileshareArtifacts@1 work?

Question

Recently i stumbled over the log outout of the DownloadFileshareArtifacts@1 task. I was a bit surprised that it was not using my expected artifact during the deployment, but has choosen a different package with the same git commit.

##[section]get-artifacts > download package is started.
==============================================================================
Task : Download artifacts from file share
Description : This is used to download artifacts from a file share such as "\\Share\Drop".
Version : 1.205.0
Author : Microsoft Corporation
Help : https://docs.microsoft.com/azure/devops/pipelines/tasks/utility/download-fileshare-artifacts
==============================================================================
Artifact "V2.0.74-patch02-75085e9" is downloaded from \\my\fileshare\2.0.74-
patch02\2023-12-07-V2.0.74-patch02-75085e9.

The directory "\\my\fileshare\2.0.74-patch02\2023-12-07-V2.0.74-patch02-75085e9" 
does not exist. Fallback to the parent directory: \\my\fileshare\2.0.74-patch02

Download from "2023-12-07-V2.0.74-patch02-75085e9\2023-12-08-V2.0.74-patch02-
75085e9\2023-12-08-V2.0.74-patch02-75085e9.zip" to "C:\_AGENTS\06\_work\1\package\2023-
12-07-V2.0.74-patch02-75085e9\2023-12-08-V2.0.74-patch02-75085e9\2023-12-08-V2.0.74-
patch02-75085e9.zip" is executed.

# Translated from german output, maybe not 100% accurate

The good thing is that he selected a new build with the same Git commit. But will that always be the case?

I have read the documentation but i did not find anything about a fallback mechanis. Does someone has more insights?

My current pipeline definition is as simple as it could be i would say:

resources:
  pipelines:
  - pipeline: package 
    source: pck-foobar
    branch: develop

[...]

  - download: package
    displayName: "get-artifacts > download package"

---

Answers to questions from comments:

1. No we have different agents for build and deployment. Building happens via an agent-pool and deployment happens via an environment-agent. Both have access rights to the file-share.

2. 2023-12-08-V2.0.74-patch02-75085e9.zip was created through a scheduled build. I would say the file was not there, but it looks like it is now. Which is quite strange. I could swear two days ago the folder was empty, because i have checked that and it would be even stranger if azure would have skipped an existing file.

3. Task configuration for publishing:

task: PublishBuildArtifacts@1
displayName: 'publish-artifacts $(Build.BuildNumber) ${{ parameters.targetPath }}'
inputs:
  PathtoPublish: $(build.artifactstagingdirectory)
  ArtifactName: $(Build.BuildNumber)
  ArtifactType: FilePath
  TargetPath: ${{ parameters.targetPath }}

Answer 1

Based on my test, if the target artifact does not exist in the shared folder, the pipeline will download all other files that already exist in the shared folder.

I am guessing the artifact "2023-12-07-V2.0.74-patch02-75085e9" was not successfully published to your shared folder, and there is already the file 2023-12-08-V2.0.74-patch02- 75085e9\2023-12-08-V2.0.74-patch02-75085e9.zip in your shared folder, so the artifact actually downloaded is it. If this is the case, you can do a simple test by adding any file to your shared folder, then run the download artifact pipeline, and the new file will also be downloaded.