Каков правильный способ использования/p на шаг сборки в конфигурации сборки TeamCity?

Question

В TeamCity я создал конфигурацию сборки с двумя строками сборки msbuild, которые должны создать файл .sln решения.

Я определил цель как «Сборка», когда я запустил сборку, оба этапа, очевидно, выполняют стандартную конфигурацию и одновременно строят конфигурацию Debug или Release дважды.

Теперь я пошел в настройки шага сборки и нашел CommandLine аргумент для Debug я добавил /p:Configuration=Debug, для Release я добавил /p:Configuration=Release.

Построение это приводит к предупреждения TeamCity:

MSBuild command line parameters contain "/property:" or "/p:". It is recommended to define System Property on Build Parameters instead. 

Хотя один отлаживать и один релиз был билд.

Я написал это сообщение и создал два System Parameters: /p:Configuration=Debug и /p:Configuration=Release. Если бы я теперь изменил свою командную строку для отладки на %system.DebugConfig% и для ее освобождения до %system.ReleaseConfig% Я получаю ту же ошибку. Только тогда я действительно понял, что эти системные параметры будут передаваться на каждый шаг сборки никогда автоматически, всегда.

Хорошо, но как правильно определить два разных этапа сборки, строящих отладку и выпуск с использованием системных параметров или без команды, жалующихся на /p в командной строке?

Answer 1

Там нет никакого способа сделать это (что я знаю, медведь со мной), но есть достаточно альтернатив:

Если вы готовы отказаться от раздельных этапов сборки и вместо того, чтобы использовать индивидуальный строит вместо этого - который обычно не должно быть никаких проблем, используйте шаблоны: создайте build template, в котором вы добавите все параметры, которые необходимо настроить, например Configuration в вашем случае и придать им соответствующие значения по умолчанию. Затем создайте конфигурацию сборки для каждой комбинации свойств, которые вы хотите, и в этой конфигурации переопределите параметры.

Другой вариант: сделайте это самостоятельно. В прошлом я переключился на несколько CI, и стало очевидным, что чем больше вы полагаетесь на функции системы CI, тем сложнее проверять сборки вручную, тем громоздок он обходит через веб-интерфейсы системы CI или базами данных или конфигурационными файлами, чтобы найти правильные параметры конфигурации, и чем больше искалечен переход на другой CI. Поэтому в какой-то момент я просто отказался от этого и написал несколько сценариев «master» msbuild, которые могли бы построить все одним щелчком кнопки, так сказать, вспомните Joel Test, но на любой машине, которую я хочу, включая мою собственную, без потребность в любом CI вообще. Это было таким облегчением, что я не оглядывался назад, и конфигурация CI теперь сведена к минимуму. Применительно к данному случаю: создать файл MSBuild, как показано ниже, и этап сборки в ТС, который вызывающее это построить цель и имеет параметр системы MyTargetProjectFile Пойтинг в реальный файл проект:

<ItemGroup> 
    <Configurations Include="Debug;Release"/> 
</ItemGroup> 

<Target Name="Build"> 
    <MsBuild Projects="$(MyTargetProjectFile)" Targets="Build" 
      Properties="Configuration=%(Configurations.Identity)"/> 
</Target> 

Еще один вариант: просто проигнорировать предупреждение Teamcity в , Мне никогда не было ясно, почему они настаивают на том, чтобы делать это таким образом, это кажется противоречивым и приводит к таким вопросам, как:] Наличие разных шагов сборки с разными свойствами кажется скорее основным требованием, нет? Я не думаю, что у нас есть какой-либо шаг msbuild, не использующий/p, и все работает отлично.