The $(Build.ArtifactStagingDirectory) variable's value changes when deploying a build in Azure DevOps Pipelines

Question

I have a DACPAC deployment task which is failing, because for some reason the value of the $(Build.ArtifactStagingDirectory) pipeline variable is changing between the build pipeline and the release pipeline. In the build pipeline, the variable is set to C:\agent\_work\2\a, but in the release pipeline it's C:\agent\_work\r2\a. This is causing the release pipeline to fail when it tries to deploy the DACPAC artifact, because the folder it's looking in is empty; the folder where the artifact actually is is ignored. How do I make these variables consistent between the build and release pipelines so that the artifact is retrieved from the same folder it's generated in? These variables appear to be built in, so I don't see any way to change them. I could always hardcode a path, but that seems a bit kludgy...

Deni

Answer 1

Oh, I think I figured it out. Each release pipeline stage has an option called "Artifact download" which lets you specify which artifacts out of all those linked in the pipeline are actually used by that stage. I needed to check the appropriate checkboxes there in order to use the artifacts in the stage's tasks.

Deni

Thanks for reminding me! For some reason SO won't let me accept an answer right away, but won't remind me when I'm finally allowed to, so I often forget... – Deni

Answer 2

In releases you have System.ArtifactsDirectory which is

The directory to which artifacts are downloaded during deployment of a release. The directory is cleared before every deployment if it requires artifacts to be downloaded to the agent. Same as Agent.ReleaseDirectory and System.DefaultWorkingDirectory.

Example: C:\agent_work\r1\a

and in pipelines/builds Build.ArtifactStagingDirectory

The local path on the agent where any artifacts are copied to before being pushed to their destination. For example: c:\agent_work\1\a

A typical way to use this folder is to publish your build artifacts with the Copy files and Publish build artifacts tasks.

Note: Build.ArtifactStagingDirectory and Build.StagingDirectory are interchangeable. This directory is purged before each new build, so you don't have to clean it up yourself.

See Artifacts in Azure Pipelines.

This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.

This is in line with your experience. And you cannot change it, as they are predefined. But can you clarify why this is a problem for you?

Segalman

Hmm. Well, as it turns out, in the release pipeline I actually am using System.DefaultWorkingDirectory. But that directory is empty; the artifacts are not there. They do exist in a folder under the build pipeline, though. When I go look at the build pipeline in Azure DevOps, I can see the artifacts. It's just that the release pipeline can't find them. – Deni

@Deni did you find a solution to your issue, I'm facing the exact same issue. Exists under the build pipeline but the release can't access it. – Underthecounter

Answer 3

In the release pipeline, you can't directly access the files in the build pipeline, not only because the working directory is different, but also because they do not use the same agent. You need to download the artifacts first, and then use them in the release pipeline.

You can use the following ways to download artifacts:

1. Use the Download Build Artifacts task.

2. Go to the edit release pipeline page -> Select Add artifact -> Select Build -> Fill in the information related to the build pipeline (Notice the value of Source alias)-> Add it. You will find your artifacts are downloaded in $(System.ArtifactsDirectory)/${Source alias}

For more information about consuming artifacts in release pipelines, you can click this document.

Cromer

Yeah, I already followed option 2 that you presented; there is an artifact being loaded. But for some reason when it comes time to actually use it, it isn't in the System.ArtifactsDirectory; it's only in the build pipeline's directory. – Deni