Azure DevOps Server – как узнать системные каталоги на другом сервере?
Я использую два разных сервера сборки: один для сборок со статическим анализом кода, другой без него, для создания крупных решений Windows.
Сборка на двух серверах работает отлично, но после этого мне нужны артефакты на одном сервере. Существует немало встроенных функций для борьбы с артефактами, но я бы предпочел вместо этого прямое копирование файла.
Это работает, если я жестко запрограммировал каталоги, например \\server1\DevOpsAgent\_work\1\b\, но у меня возникнет проблема, если каталог не равен «1» или если имя сервера изменится (я выбираю серверы только по требованиям агента).
Есть ли способ во время выполнения узнать, какие каталоги использует «другой» сервер?
Не нашел ответа ни в документации Microsoft, ни в Интернете.
Ответы 1
TL;DR использует артефакты конвейера (или, как альтернатива, универсальные пакеты) вместо прямой копии файла.
... Мне нужны артефакты на одном сервере. Существует немало встроенных функций для борьбы с артефактами, но я бы предпочел вместо этого прямое копирование файла.
Честно говоря, я не понимаю, как использование прямого копирования файлов могло бы упростить ситуацию, особенно учитывая проблемы, с которыми вы уже столкнулись - использование требований к агентам, пути, которые могут (и, вероятно, будут) меняться, среди прочего.
Кроме того, вы пытаетесь изобрести велосипед, используя обходной путь для решения проблемы, которая уже давно была решена многими платформами CI/CD: публикация и использование артефактов между конвейерами.
Использование артефактов конвейера
В большинстве случаев использование артефактов конвейера довольно просто — конвейер публикации генерирует артефакты в папку, копирует эти файлы в промежуточный каталог (необязательно) и затем публикует эти артефакты:
# Generate artifacts into the $(Build.ArtifactStagingDirectory) folder
- task: VSBuild@1
inputs:
solution: '**/*.sln'
msbuildArgs: 'p:DesktopBuildPackageLocation = "$(Build.ArtifactStagingDirectory)\WebApp.zip" ...
platform: 'Any CPU'
configuration: 'Release'
# Publish files from $(Build.ArtifactStagingDirectory) folder as artifacts
- task: PublishPipelineArtifact@1
inputs:
targetPath: $(Build.ArtifactStagingDirectory)
artifactName: WebApp
Потребляющий конвейер/этап/задание загружает артефакты, а затем использует их для развертывания приложений, запуска сценария и т. д.
- task: DownloadPipelineArtifact@2
inputs:
artifact: WebApp
targetPath: '$(System.DefaultWorkingDirectory)'
- task: AzureRmWebAppDeployment@4
inputs:
# other properties here
packageForLinux: '$(System.DefaultWorkingDirectory)/**/*.zip'
Вы не публикуете артефакты в другом агенте — вы публикуете артефакты в Azure DevOps или в общем файловом ресурсе, а затем в потребительском конвейере загружаете эти артефакты, как указано в первой ссылке моего ответа. Пожалуйста, внимательно прочитайте документацию.
Чтобы внести ясность: артефакты не привязаны к агенту сборки или серверу. Они будут опубликованы в Azure DevOps (в идеале) или в общей папке, доступной любому другому агенту сборки. Точно так же, как канал nuget или npm, где один конвейер может публиковать пакет, а другой конвейер может создавать приложение, используя тот же пакет, без знания каких-либо подробностей о конвейере или агенте, опубликовавшем этот пакет.
using PublishBuildArtifacts@1 to a network file path makes it very simple to copy to a network directory. But how can I publish to another agent on a different machine during a DevOps run? - не уверен, что понял последнее предложение - вы имеете в виду как скачать артефакты в другой сборке? Это зависит от того, как вы настроите свой конвейер. Пожалуйста, отредактируйте свой вопрос и покажите нам, как вы публикуете артефакты.
вы абсолютно правы, использование встроенных функций для публикации артефактов значительно облегчает жизнь. Мы используем DevOps Server, а использование PublishBuildArtifacts@1 для сетевого пути к файлу упрощает копирование в сетевой каталог. Но как я могу опубликовать данные для другого агента на другом компьютере во время выполнения DevOps?