CODEWITHSUNDEEP
azure-devopsazure-devops-server-2019
AxD
AxD

Reputation: 3158

Where are the artifacts after having built, to be used by release?

I'm new to Aure DevOps. Trying to create build and release pipelines there's one thing I don't understand:

Commonly, every kind of build finally results in some output, called artifacts.

With Azure DevOps it seems like there is always a final copy or publish task necessary to copy the created artifact from A to B, so the release task may then access the compiled artifacts.

Why aren't these artifacts plain accessible to a release pipeline right from the location where they have been built? Why don't the build tasks automatically set a variable pointing to the right folder, so the release pipeline may access the files right from there?

Or is this already happening and I'm just missing something from the tutorials I watched?

Upvotes: 1

Views: 876

Answers (2)

Leo Liu
Leo Liu

Reputation: 76670

Why aren't these artifacts plain accessible to a release pipeline right from the location where they have been built?

Agree with Daniel.

The main reason for me is because we can't hold the hosted agent all the time. Since MS wants to protect resources efficiently, it is not occupied for a long time.

When we queue a build, MS will assign us a brand new clean agent to execute our task, and after the build is complete, the MS will reclaim the agent assigned to our build and restore the agent to its initial state in preparation for accepting the assignment of the next task.

So, we could not keep hold the hosted agent to use it in next release pipeline. We have to store the artifacts in the cloud/server, then we could download it in the release pipeline. Otherwise, we could not get the artifact we need from an agent that has been restored.

Besides, MS is randomly assigned to the agent, and we cannot guarantee that the same agent will be allocated and built during the release pipeline.

That is the main reason why we need to copy or publish the artifacts.

If you do not want to copy or publish the artifacts, you could setup your own private agent, and do not clean the agent before you execute the release pipeline.

Update:

why is the user, well, bothered to find a place for the artifacts manually? I would have expected every build pipeline to come with a personal space to store the latest build artifacts. A space where Azure DevOps automatically copies the build artifacts to. To me it looks like things have to be manually copied from A to B and then later from B to C.

That because not all output is needed, for example, the test project, what we need is test result/Code coverage for the test project, not the output for the solution. In this case, we do not need to copy the output to the artifacts. On the other hand, we need to copy some special files to artfacts, then automatically copy the build artifacts will not meet your requirements.

That is also the reason why we provide the task to copy files to artifacts, so that we could customize our personality needs.

Of course, if you think that manual copying is superfluous, you can use the MSBuild parameter /p:output=$(build.artifactstagingdirectory) to set the output directly to artifacts.

If I need to copy things from A to B in the Build pipeline, then what should keep me from copying it to C right away? Then a separate Release pipeline would be, well, rather optional, if not redundant.

If you are in the build pipeline, there is another task Download build artifacts, which could download the build artifacts.

if you are in the release pipeline, you just need select the build artifacts as source, release pipeline will download that artifact automatically:

enter image description here

Check this document for some more details.

Hope this helps.

Upvotes: 0

Daniel Mann
Daniel Mann

Reputation: 58981

There are so many reasons.

Two easy ones:

  • There is no guarantee that the agent's working folder still contains the files. Agents are reused from build to build and release to release, and a given build or release will always use the same working folder. The working folder is cleaned up between builds.
  • Releases may run on different agents. On different machines. In different domains. Or any combination. There's no guarantee that the agent where the build ran is accessible by the agent where the release is running. Publishing the artifact allows a guarantee: As long as the machine the release is running on has the ability to talk to Azure DevOps (which is a requirement for the agent to function in the first place), it can get the artifacts it needs.

Upvotes: 1

Related Questions