在 Azure Devops 中，有没有办法让构建/工作目录在作业中持续存在？答案

【问题标题】：In Azure Devops is there a way to make the build / working directory persist across jobs?在 Azure Devops 中，有没有办法让构建/工作目录在作业中持续存在？
【发布时间】：2020-09-10 14:30:53
【问题描述】：

我在 Azure Devops 中有一个管道，我目前正在尝试加快它的速度。目前它是一项运行一堆步骤/任务的工作。基本大纲是 1：构建，2：测试运行，3：符号文件发布到符号服务器，4：nuget 包打包和推送，5：工件发布。

3、4、5，仅取决于正确的构建并在技术上同时运行。问题是当我尝试将它们分解为单独的作业（取决于构建的完成）时它不起作用，因为在构建期间创建的目录在其他作业运行时不可用。

有没有办法让工作目录持续存在，直到管道中的所有作业都完成？

【问题讨论】：

您使用的是发布任务吗？如果是，是 publishbuildartifacts 还是 publishpipelineartifacts？
我正在使用 publishpipelineartifacts

标签： azure azure-devops yaml azure-pipelines

【解决方案1】：

有没有办法让工作目录持续到所有作业在管道中完成了吗？

否，如果您使用的是Microsft-Hosted agent，是，如果您使用的是self-hosted agent。

对于托管代理：该文档指出each time you run a pipeline, you get a fresh virtual machine。但实际上是each time you run a job, you get a fresh virtual machine。这就是为什么第二个作业无法访问第一个作业的工作目录的原因，它们是不同的虚拟机。

因此，如果您想为这两个作业创建一个工作目录，则只能使用自托管代理。您可以查看this issue 了解更多详情。由于这两个作业应该在同一个自我代理中运行，我建议使用demands 指定您要选择的代理。

注意：我们在使用托管代理时不能保留工作目录，但是我们可以使用Publish Artifact task and Download Artifact task在不同代理的不同作业之间共享文件。示例：

jobs:
- job: MyJob1
  continueOnError: true
  steps:
  - task: PublishBuildArtifacts@1
    inputs:
      PathtoPublish: '$(System.DefaultWorkingDirectory)'
      ArtifactName: 'drop'
      publishLocation: 'Container'
- job: MyJob2
  continueOnError: true
  dependsOn: MyJob1
  steps:
  - download: none
  - task: DownloadBuildArtifacts@0
    inputs:
      buildType: 'current'
      downloadType: 'single'
      artifactName: 'drop'
      downloadPath: '$(System.DefaultWorkingDirectory)'

我在 Azure Devops 中有一个管道，我目前正在尝试加速它起来。

不建议将它们分解为单独的作业，我认为这实际上不会加快进程。您的步骤 3.4.5 取决于步骤 1.2 的完成，如果您在 Job1 中添加 1.2 并在 Job2 中添加步骤 3.4.5，您仍然无法进行并行作业以加快速度，因为 Job2 必须等待 直到 Job1 完成。

【讨论】：

我认为即使在自托管中它也不会像您描述的那样工作。如果重点是重新使用创建的工件，那么清理工作区：输出将清除创建的目录。您可能在同一个 _work/1/ 文件夹中的同一台服务器上……但它会删除您想要保留的任何内容。
是的，这与我需要的非常接近，但看起来我可能不得不等到 Azure 允许运行并行任务，这是一个已经提出的问题 (developercommunity.visualstudio.com/idea/365659/…)
@cybersnow1989 看来我们必须等待一段时间才能实现此功能请求。
@cybersnow1989 由于上述功能暂时不可用，您可以尝试使用自托管代理运行管道。这样您的输出就在同一台机器上。

【解决方案2】：

我认为不一定保证并行作业在处理 1 和 2 的同一代理上运行。它们甚至可能不在同一台服务器上，因此它无法引用在第 1 步和第 2 步。通常，如果您想并行执行某些操作，您会发布管道或构建工件，然后在后续相关作业中执行一个步骤以将它们拉下来。由于您想要并行的任务就像发布一样，我不确定是否真的能够并行运行。

【讨论】：