Загрузка артефакта из прародителя Azure DevOps Pipeline

Question

Имеется 3 конвейера AzOv DevOps (может существовать больше):

1. Построение, модульный тест, публикация артефактов
2. Развертывание, тестирование интеграции
3. Развертывание производства, тест дыма

Как я могу обеспечить, чтобы Pipeline 3 загружал конкретные артефакты, опубликованные в Pipeline 1?

Сложность, как я понимаю, заключается в том, чтоЗадача DownloadPipelineArtifact@2 предлагает способ сделать это только в том случае, если артефакт поступил из непосредственно предшествующего конвейера. Используя следующую задачу конвейера:

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

Это прекрасно работает для родительского "запускающего конвейера", но не для бабушки и дедушки. Вместо этого он возвращает сообщение об ошибке:

Артефакт example.zip не найден для сборки nnn.

где nnn - идентификатор запуска непосредственного предшественника, как будто яуказал pipelineId: $(Build.TriggeredBy.BuildId). По сути, Pipeline 3 пытается извлечь артефакт Pipeline 1 из Pipeline 2. Было бы неплохо, если бы эта линия definition: 1 что-то сделала, но, увы, она, похоже, ничего не делает, когда установлена ​​specificBuildWithTriggering: true.

Примечаниечто buildType: 'latest' не безопасно;По-видимому, он позволяет публиковать непроверенный артефакт, если он испускается из конвейера 1 во время работы конвейера 2.

Может быть невозможно выполнить это с DownloadPipelineArtifact@2. Трудно быть уверенным, потому что документация не содержит подробностей. Возможно, есть другой разумный способ сделать это ... Я предполагаю, что публикация другой копии артефакта на каждом из промежуточных конвейеров, даже тех, которые его не используют, является одним из способов, но не очень разумным. Мы могли бы устранить уродливый аспект создания копий двоичных файлов, вместо этого опубликовав артефакт с записанным в нем BuildId, но нам все равно пришлось бы получать его и повторно публиковать из каждого конвейера.

Если естьспособ идентифицировать исходный триггер CI, например, найти хэш инициирующего коммита GIT, я мог бы использовать его для именования и ссылки на артефакты. Build.SourceVersion остается постоянным между запущенными сборками? Любой другой «Инициирующий идентификатор» будет работать одинаково хорошо.

Вы можете прокомментировать пример сценария конвейера, так как я на самом деле его использую, но это не вопрос моего вопроса. Я думаю, что эта проблема широко применима, поскольку она будет применяться при сборке зависимых пакетов или по любым другим причинам, для которых полезны «Триггеры».

Answer 1

Представитель MS предложил использовать для этого REST . Например:

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

-

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

Гуляя с родителями, можно найти предка с желаемым идентификатором определения (например, 10). Затем его идентификатор запуска (например, 2535) можно использовать для загрузки артефакта.

@ merlin-liang-msft предложил аналогичный процесс для другого требования из @sschmeck, и их ответ имеетсопровождающий код.

Answer 2

Одним из способов является использование конвейеров выпуска (вы не можете кодировать / редактировать его в YAML), но вы можете использовать одни и те же артефакты во всем развертывании.

Выпуск конвейера

Вы также можете указать необходимые триггеры для запуска развертывания на

Утверждение и триггеры

В качестве альтернативы, существует многоступенчатый конвейер, который находится в режиме предварительного просмотра. (https://devblogs.microsoft.com/devops/whats-new-with-azure-pipelines/). Вы можете получить к нему доступ, включив его в «функции предварительного просмотра».

Answer 3

Существуют расширения, которые позволяют вам делать это , но официальное решение использует многоступенчатый конвейер , а не 3 независимых конвейера.