从 Azure DevOps Pipeline 祖父 Pipeline 下载工件答案

【问题标题】：Download artifact from Azure DevOps Pipeline grandparent Pipeline从 Azure DevOps Pipeline 祖父 Pipeline 下载工件
【发布时间】：2019-10-13 16:13:02
【问题描述】：

给定 3 个 Azure DevOps Pipelines（可能还有更多），如下：

构建、单元测试、发布工件
部署暂存、集成测试
部署生产、冒烟测试

如何确保 Pipeline 3 下载 Pipeline 1 中发布的特定工件？

在我看来，挑战在于任务DownloadPipelineArtifact@2 仅在工件来自前一个管道时才提供执行此操作的方法。通过使用以下管道任务：

- task: DownloadPipelineArtifact@2
  inputs:
    buildType: 'specific'
    project: '$(System.TeamProjectId)'
    definition: 1
    specificBuildWithTriggering: true
    buildVersionToDownload: 'latest'
    artifactName: 'example.zip'

这适用于父“触发管道”，但不适用于祖父。相反，它返回错误消息：

找不到构建 nnn 的工件 example.zip。

其中 nnn 是直接前任的运行 ID，就好像我指定了 pipelineId: $(Build.TriggeredBy.BuildId)。实际上，Pipeline 3 尝试从 Pipeline 2 中检索 Pipeline 1 工件。如果 definition: 1 行做了一些事情会很好，但是，当设置了 specificBuildWithTriggering: true 时，它似乎什么都不做。

请注意，buildType: 'latest' 不安全；如果在管道 2 运行时从管道 1 发出，它似乎允许发布未经测试的工件。

DownloadPipelineArtifact@2 可能无法实现此目的。很难确定，因为the documentation 没有太多细节。也许还有另一种合理的方式来实现这一点......我想在每个中间管道上发布工件的另一个副本，即使是那些不使用它的管道，是一种方式，但不是很合理。我们可以通过发布一个记录了 BuildId 的工件来消除创建二进制文件副本的丑陋方面，但我们仍然必须从每个管道中检索并重新发布它。

如果有办法识别原始 CI 触发器，例如找到启动 GIT 提交的哈希值，我可以使用它来命名和引用工件。 Build.SourceVersion 在触发的构建之间是否保持不变？任何其他“启动 ID”都可以正常工作。

欢迎您对示例管道场景发表评论，因为我实际上正在使用它，但这不是我问题的重点。我认为这个问题是广泛适用的，因为它适用于构建依赖包时，或者出于任何其他“触发器”有用的原因。

【问题讨论】：

听起来类似于stackoverflow.com/q/58285153/846163。
同意 sschmeck。问题当然是不同的，因为在您的情况下，您希望在管道开始时使用最新的，您将使用简单的管道变量将其锁定。就我而言，我想要原始触发器的工件。但是，我刚刚在此处添加的有关使用 REST 的答案与您的答案中的建议非常相似，我现在将其链接到下面。

标签： azure-devops azure-pipelines azure-artifacts

【解决方案1】：

为此提供MS representative suggested using REST。例如：

HTTP GET https://dev.azure.com/ORGNAME/PROJECTGUID/_apis/build/Builds/2536

{
    "id": 2536,
    "definition": {
        "id": 17
    },
    "triggeredByBuild": {
        "id": 2535,
        "definition": {
            "id": 10
        }
    }
}

通过遍历父母，可以找到具有所需定义 ID（例如 10）的祖先。然后它的运行 ID（例如 2535）可用于下载工件。

@merlin-liang-msft 建议 a similar process 满足与 @sschmeck 不同的要求，他们的答案附有代码。

【讨论】：

非常感谢这里分享的这个解决方案。您可以接受此答案，因此具有相同需求和问题的其他 SO 用户可以参考此解决方案：-)
@MerlinLiang-MSFT 同意，但我觉得如果没有代码，答案是不完整的。我正在尝试抽出时间提交具有此功能的 PR 增强 DownloadPipelineArtifact@2，然后所有人都可以得到答案。
非常感谢您对我们产品的认真和贡献。如果需要任何帮助，请随时在我们的论坛上提出问题。

【解决方案2】：

有extensions that allow you to do this，但是官方的解决方案是use a multi-stage pipeline而不是3个独立的管道。

【讨论】：

我目前在我的管道中使用阶段，以区分任务的并行和顺序分组。我感谢您的建议完全有效，但希望有另一种不会给我带来新挑战的方法。
您链接的扩展程序已停止使用，并且看起来不能确保使用祖先运行工件......只是任何运行工件。这已经可以通过内置的工件任务来完成。

【解决方案3】：

一种方法是使用发布管道（您不能在 YAML 中对其进行编码/编辑），但您可以在整个部署过程中使用相同的工件。

Release pipeline

您还可以指定启动部署所需的触发器

Approval and triggers

或者，存在多阶段管道，正在预览中。（https://devblogs.microsoft.com/devops/whats-new-with-azure-pipelines/）。您可以通过在“预览功能”中启用它来访问它。

【讨论】：

这是一个非常有趣的建议。我们希望在第 2 步和第 3 步之间添加批准。正在调查...

【解决方案4】：

你为什么不输出一些带有元信息的管道工件并将它们连接到前面的管道中。

祖父母>关于管道的元数据 Parent > 关于管道和授权父元的元

等等

【讨论】：

您的解决方案对我来说很有意义。我认为这就是我最终采用的方法，问号？哈哈。如果我记得，可靠地识别/维护正确祖先的元数据仍然存在一些挑战。