0 Вопрос: Есть ли способ запретить VSBuild Jobs очистить каталог bin?

вопрос создан в Thu, May 2, 2019 12:00 AM

Я пытаюсь создать конвейер DevOps Azure, который создает несколько двоичных файлов C # с использованием нескольких конфигураций.

Похоже, что рекомендуемый способ сделать это - использовать несколько «заданий», а не несколько шагов. В частности, я использую матрицу для определения, Debug | AnyCPU, Release | AnyCPU, Custom | AnyCPU.

Это заставляет все строить просто отлично. Проблема в том, что каждое «Задание» очищает каталог bin, поэтому в конце процесса в моем каталоге bin только одна сборка.

Мне нужны все библиотеки там. Цель состоит в том, чтобы создать пакет NuGet, содержащий все сборки. Я рассмотрел вопрос об использовании каталога StageArtifacts Azure DevOps. Я просто хотел бы попытаться избежать слишком большого различия между сборкой на машине разработчика и сборкой на машине сборки.

Я указываю отдельные пути вывода для каждой конфигурации. На моем компьютере разработчика, я могу пакетно собрать все, и все отображается в каталоге bin.

strategy:
    matrix:
      debug-job:
        buildConfiguration: 'Debug'
      release-job:
        buildConfiguration: 'Release'
      custom-job:
        buildConfiguration: 'Custom'
<OutputPath Condition=" '$(OutputPath)' == '' ">bin\$(Configuration)\$(TargetFrameworkVersion)\</OutputPath>
    
0
  1. Почему бы не опубликовать несколько наборов артефактов сборки, а затем создать определение выпуска, которое генерирует и выталкивает пакет NuGet из наборов артефактов?
    2019-05-02 15: 15: 05Z
  2. Я думаю, я не вижу причин хранить больше артефактов, чем мне нужно. Пакет NuGet будет в основном для внутреннего использования. Некоторым внутренним клиентам понадобятся все 3 сборки, а другим может просто понадобиться 1. Кажется, что больше обслуживания требует наличия нескольких артефактов против 1. Кроме того, если я использую промежуточные артефакты, то nuspec для машины сборки будет отличаться от того, что Разработчик может сделать на своей машине разработчика. Я бы хотел избежать различий между конфигурациями машин dev и build.
    2019-05-02 15: 22: 32Z
  3. Почему NuSpec должен отличаться? Ваше определение релиза будет отвечать за захват артефактов, «массирование» их в соответствующую структуру папок и их упаковку /отправку в ленту артефактов.
    2019-05-02 15: 25: 59Z
  4. Так что я довольно новичок в создании nuspecs. Думая об этом, похоже, что это на самом деле может работать довольно хорошо. Я мог бы имитировать расположение каталога bin во время конвейера выпуска, а затем использовать переменную, чтобы разрешить начало пути. Это позволило бы и разработчикам, и сборщикам создавать пакеты NuGet. Полагаю, мне просто нужно выяснить, как разработать промежуточный каталог. Я предполагаю, что на самом деле мне не нужно сохранять свои двоичные файлы на сервере артефактов. Есть ли проблема с тем, что конвейер выпуска перестраивает эти сборки до того, как я буду готов опубликовать?
    2019-05-02 15: 31: 49Z
  5. Нет необходимости перестраивать ваш конвейер выпуска. Здесь может быть небольшая путаница в терминологии: «артефакт» - перегруженный термин. В контексте сборки это означает опубликовать артефакт сборки ( docs.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/… ), который связан с сборка, не фид артефактов.
    2019-05-02 15: 38: 10Z
0 ответов                              0                         
источник размещен Вот