azure-pipelines-tasks: Publish Pipeline Artifact task fails when path to publish is a file

Agent Version and Platform

Version: 2.140.2 OS: Hosted Ubuntu 1604

Task Type and Version

==============================================================================
Task         : Publish Pipeline Artifact
Description  : Publish Pipeline Artifact
Version      : 0.139.0
Author       : Microsoft Corporation
Help         : Publish a local directory or file as a named artifact for the current pipeline.
==============================================================================

What’s not working?

The task fails when Path to publish points to a file rather than a directory.

image

Task Logs

When publishing a file: (fails)

2018-10-18T17:37:09.0819573Z Uploading pipeline artifact from /home/vsts/work/1/s/dist.zip for build #15
2018-10-18T17:37:11.6205372Z ##[error]Microsoft.VisualStudio.Services.BlobStore.WebApi.Exceptions.InvalidLocalDirectoryException: The source directory provided does not exist, or is not a directory.
   at Microsoft.VisualStudio.Services.BlobStore.WebApi.BuildDropManager.<PublishAsync>d__12.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Agent.Plugins.PipelineArtifact.PipelineArtifactServer.<UploadAsync>d__2.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Agent.Plugins.PipelineArtifact.PublishPipelineArtifactTask.<ProcessCommandInternalAsync>d__2.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Agent.Plugins.PipelineArtifact.PipelineArtifactTaskPluginBase.<RunAsync>d__6.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Agent.PluginHost.Program.Main(String[] args)

When publishing a directory: (succeeds)

2018-10-18T17:37:12.1639551Z Uploading pipeline artifact from /home/vsts/work/1/s for build #15
2018-10-18T17:37:14.0002031Z Information, 9318 files to be processsed in 94 groups.
<...>
2018-10-18T17:38:02.8487800Z Information, Upload is done!
2018-10-18T17:38:02.8506948Z 
2018-10-18T17:38:04.8750126Z Associated artifact 1 with build 15
2018-10-18T17:38:04.8752235Z Uploading pipeline artifact finished.

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 4
  • Comments: 18 (4 by maintainers)

Commits related to this issue

Most upvoted comments

OK I’ve logged a bug for this. In the meantime if you want to specify the directory go right ahead. If you have files in the directory along with the file you want to upload you can use the .artifactignore file to constrain what you publish:

https://docs.microsoft.com/en-us/azure/devops/artifacts/reference/artifactignore?view=vsts

@federicorinaldi perhaps that is poorly worded or miscommunication of the writer, for me a file path is not path to file. A file path is \server\share not a \server\share\file.ext so maybe an assumption of the writer vs English terms.

While I agree that this causes a longer build time as youre copying files from one folder on the agent to another folder on the same agent BUT, as you probably know, compiling code leaves extra unnecessary files that were brought over by the “Get Sources” step and the Build process itself, so this allows you to more then tell the Copy step what to copy its what NOT to copy, depending on how you set your Build Output parameter. Ifyou set a special folder for the output then yes, you do NOT need the Copy step, but ive seen way more times in my work as DevOps and ALM consultant that the current method a company uses, creates folders with mass amounts of ‘garbage’ that has no reason to be promoted as an artifact so that Copy step is essential for the beginning to make them start working correctly and then in the second step we fix the build procedure so that extra copy step is not needed.

That said, because the copy and publish steps, both use Robocopy, the copy of the files is very fast, especially if you tell it what to copy and what NOT to copy.

If youre comfortable with the output of the Build and used a zip file to archive, simply state in the Archive step to place the zip under a ‘Output’ folder, which will make the zip the ONLY file in it and then the Publish step will take it from that folder.

@tvald While documentation is lacking at times, you and I have the power to fix it and offer fixes via opening a pull request. I’ve done so myself couple of time in the past, with ease.

However I completely disagree with your statement concerning the maturity of Azure Devops. As someone who worked with TFS when it was Visual source safe, seeing the transition and helping numerous organizations convert to it and use it, its a Delightful experience and the service is very mature, very intuitive and allows degree of freedom to do whatever you want with it, if you write your own PowerShell scripts, your own extension and your own applications to interact with the RESTAPI it offeres.

Try to upload a node project as artifact. After half an hour, it still uploading files from node_modules… 🤣

Why it download as a zip file, but upload as files…