Question

给出3条Azure DevOps管道（可能存在更多），如下所示：

构建，单元测试，发布工件
部署登台，集成测试
部署生产，冒烟测试

如何确保管道3下载了管道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)一样。有效地，管道3尝试从管道2检索管道1工件。如果definition: 1行做了什么，那很好，但是，a，设置specificBuildWithTriggering: true时它什么也没做。

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

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

如果有一种方法可以识别原始CI触发器，例如找到发起GIT提交的哈希，我可以用它来命名和引用工件。 Build.SourceVersion在触发的生成之间是否保持不变？任何其他“启动ID”也将同样有效。

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

Answer 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提出不同的要求，他们的答案带有随附的代码。

Answer 2

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

Answer 3

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

Release pipeline

您还可以指定所需的触发器以在

上开始部署

Approval and triggers

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

Answer 4

为什么不输出一些带有元信息的管道工件，并将它们串联在前面的管道中，例如。

祖父母>关于烟斗的元数据 Parent>有关管道的元数据和Grantparent元数据

等

从Azure DevOps Pipeline祖父母管道

4 个答案: