Azure DevOps: создание проекта 1 в многопроектном решении

Question

Я не уверен, что я ищу правильно, но я надеюсь, что я могу получить некоторые указания здесь.

Текущая настройка

У меня есть одинрешение с двумя проектами:

1. проект Web API
2. проект Node.js

Я использую Azure DevOps с 2 Builds каждыйсо своими Releases, по одному на каждый проект.Каждое определение сборки срабатывает только при обновлении / изменении соответствующего проекта.

Это прекрасно работает!

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

Проект Web Api не зависит от изменений в проекте Node.js, однако Node.js может зависеть от изменений в Web Api.Из-за этого, если Web Api не работает, я не хочу, чтобы Node.js собирал / выпускал.

Цели

Что я пытаюсь сделатьнастраивает мои определения сборки так, чтобы сборка Web Api строила только проект Web Api.Независимо от того, завершится он или выдает ошибку, пусть сборка продолжается как обычно.

Однако я хочу, чтобы проект Node.js собирал как Web Api , так и проект Node.js, поэтомучто если сборка Web Api завершится неудачно, то вся сборка завершится неудачей, даже если Node.js не потерпит неудачу.

Я попытался добавить новый Visual Studio Build task и выбрать только проект, но получилследующая ошибка:

[предупреждение] C: \ Program Files (x86) \ Microsoft Visual Studio \ 2017 \ Enterprise \ MSBuild \ 15.0 \ Bin \ Microsoft.Common.CurrentVersion.targets (781,5): Предупреждение. Свойство OutputPath не установлено для проекта «MyProject.csproj».Пожалуйста, убедитесь, что вы указали правильную комбинацию конфигурации и платформы для этого проекта.Конфигурация = «релиз» Платформа = «любой процессор».Возможно, вы видите это сообщение, потому что вы пытаетесь построить проект без файла решения и указали нестандартную конфигурацию или платформу, которые не существуют для этого проекта.

I'mв настоящее время ищу способ исправить это, но я хочу задать следующие вопросы на случай, если я иду в неправильном направлении.

Вопросы

1. Какя могу настроить определение сборки только для одного проекта?
2. Есть ли другая конфигурация, которую я должен создать вместо той, о которой я упоминал?

Определение сборки

Answer 1

То, что я пытаюсь сделать, - это настроить определения сборки так, чтобы сборка Web Api строила только проект Web Api. Завершит ли он или выдает ошибку, пусть сборка продолжается как обычно.

Это тот случай, когда вам нужно определение сборки, нацеленное на файл проекта вместо .sln. Ваша ошибка в том, что для построения .csproj требуется, чтобы у свойства OutputPath было значение, поэтому просто добавьте его в поле MSBuild Arguments : /p:OutputPath="$(build.binariesDirectory)\MyProject". Build.BinariesDirectory является предопределенной переменной, но в противном случае не является обязательным значением каталога. Вы можете использовать то, что имеет для вас смысл.

Я хочу, чтобы проект Node.js собирал как Web Api, так и проект Node.js, чтобы в случае сбоя сборки Web Api не работала вся сборка, даже если Node.js не потерпел бы неудачу.

Самый простой и наименее сложный способ

Из того, что я понимаю о вашей ситуации, в этом случае не требуется никаких дополнительных изменений. Если вы создадите решение, то конвейер потерпит неудачу, если один из проектов будет сорван. Недостатки этого:

1. Проект Node.js не «получает» последние изменения в «зависимости» веб-API, пока проект Node.js не будет изменен и CI не запустит сборку
2. Если вы используете триггер завершения сборки для уменьшения недостатка 1 выше, проект Web API создается дважды, хотя мы знаем, что он должен быть успешным оба раза

Более сложный и изощренный (но элегантный?) Способ

Установите Триггер завершения сборки в конвейере Node.js, который будет запускать сборку при успешном конвейере Web API. Это похоже на то, что у вас сейчас, с некоторыми отличиями. После завершения сборки и запуска CI в вашем конвейере Node.js сборка Web API может завершиться успешно независимо от результата нижестоящего Node.js, но вы будете создавать проект Node.js, даже если в этот проект не внесены изменения. в явном виде. (Возможно, это не то, что вам нужно, если вы пытаетесь сэкономить на активности агента)

Ваш конвейер Node.js может иметь 2 отдельных этапа сборки, каждый из которых нацелен на один из файлов проекта. Тем не менее, шаг для сборки проекта Web API может иметь условие , которое НЕ выполняется, если Build.Reason равно BuildCompletion . Это позволяет Node.js быть нижестоящим проектом Web API, но не создает Web API, если мы уже знаем, что он успешен.

Примечание: в зависимости от того, как ваши ссылки работают между этими проектами в этом решении, вам может понадобиться добавить другие задачи для загрузки артефактов сборки и что-то, чтобы убедиться, что все находится там, где должно быть для сборки.