Publish Build Artifacts task

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018


This task is deprecated. We recommend that you use the Pipeline Artifacts task instead. The current version of the Pipeline Artifacts task scales better, allows parallel uploads, and is faster.

Use this task in a build pipeline to publish build artifacts to Azure Pipelines, TFS, or a file share.



YAML snippet

# Publish build artifacts
# Publish build artifacts to Azure Pipelines or a Windows file share
- task: PublishBuildArtifacts@1
    #pathToPublish: '$(Build.ArtifactStagingDirectory)' 
    #artifactName: 'drop' 
    #publishLocation: 'Container' # Options: container, filePath
    #targetPath: # Required when publishLocation == FilePath
    #parallel: false # Optional
    #parallelCount: # Optional
    #fileCopyOptions: #Optional
    #storeAsTar: false # Optional


Argument Description
Path to publish
The folder or file path to publish. This can be a fully qualified path or a path relative to the root of the repository. Wildcards are not supported. See Artifacts in Azure Pipelines.
Default value: $(Build.ArtifactStagingDirectory)
Artifact name
Specify the name of the artifact that you want to create. It can be whatever you want.
Default value: drop
Artifact publish location
Choose whether to store the artifact in Azure Pipelines (Container), or to copy it to a file share (FilePath) that must be accessible from the build agent. To learn more, see Artifacts in Azure Pipelines.
Default value: Container
File share path
required, if publishLocation=FilePath
Specify the path to the file share where you want to copy the files. The path must be a fully qualified path or a valid path relative to the root directory of your repository. Publishing artifacts from a Linux or macOS agent to a file share is not supported.
Parallel copy (Azure Pipelines, TFS 2018, or newer)
Select whether to copy files in parallel using multiple threads for greater potential throughput. If this setting is not enabled, a single thread will be used.
Parallel count (Azure Pipelines, TFS 2018, or newer)
Enter the degree of parallelism (the number of threads) used to perform the copy. The value must be at least 1 and not greater than 128. Choose a value based on CPU capabilities of the build agent.
Default value: 8
File copy options
Pass additional options to the Robocopy command. For example, the recursive minimatch pattern **/*.
Tar the artifact before uploading
Add all files from the publish path to a tar archive before uploading. This option allows you to preserve the UNIX file permissions. Use extractTars option of DownloadBuildArtifacts task to extract the downloaded items automatically. Ignored on Windows.
Default value: false
Control options


You cannot use Bin, App_Data and other folder names reserved by IIS as an Artifact name because this content is not served in response to Web requests. Please see ASP.NET Web Project Folder Structure for more details.


- task: CopyFiles@2
    contents: '_buildOutput/**'
    targetFolder: $(Build.ArtifactStagingDirectory)
- task: PublishBuildArtifacts@1
    pathToPublish: $(Build.ArtifactStagingDirectory)
    artifactName: MyBuildOutputs


Q: I'm having issues with publishing my artifacts. How can I view the detailed logs?

To enable detailed logs for your pipeline:

  1. Edit your pipeline and select Variables
  2. Add a new variable with the name System.Debug and value true
  3. Save

Q: Which variables are available to me?

A: $(Build.SourcesDirectory) and $(Agent.BuildDirectory) are just few of the variables you can use in your pipeline. Variables are available as expressions or scripts.

See Define variables, predefined variables, and Classic release and artifacts variables to learn about the different types of variables.

Q: Task allows me to publish artifacts in deployment job in yaml pipeline, but I am not able to use it in downstream pipeline?

A: Deployment jobs do not have the context of source branches and are hence not appropriate for publishing artifacts. They have been primarily designed to consume artifacts. A workaround would be to isolate that logic into a separate job (with dependencies on your deployment jobs).