在TeamCity构建配置中使用/ p每个构建步骤的正确方法是什么？

Question

在TeamCity中,我创建了一个带有两个msbuild构建步骤的构建配置,它应构建一个Solution .sln文件.

我将目标定义为"Build",当我运行构建时,两个步骤显然都执行标准配置,并且两次构建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.

虽然已经构建了一个调试版和一个版本.

我用Google搜索了这条消息并创建了两个System Parameters:/p:Configuration=Debug和/p:Configuration=Release.如果我现在将我的命令行更改为调试到%system.DebugConfig%和释放到%system.ReleaseConfig%我得到相同的错误.只有这样,我才真正明白,这些系统参数永远不会自动传递给每个构建步骤.

好的,但是如何正确定义两个不同的构建步骤,使用系统参数构建调试和发布,或者没有团队城市抱怨/p在命令行中找到？

Answer 1

没有办法做到这一点(我知道,承担我),但有足够的选择:

如果您愿意删除单独的构建步骤而是使用单独的构建 - 通常不应该是任何问题,请使用模板:创建一个构建模板,在其中添加必须可配置的所有参数,如Configuration您的情况和给他们合适的默认值.然后为所需的每个属性组合创建构建配置,并在该配置中覆盖参数.

另一种选择:自己动手.我过去在几个CI之间进行了切换,很明显,你越依赖CI系统的功能,手动测试构建越难,爬过CI系统的Web界面就越麻烦数据库或配置文件以找到正确的配置参数,并且转换到另一个CI变得更加残缺.所以有一次我放弃了它并编写了几个msbuild'master'脚本,只需点击一下按钮即可构建所有内容,可以这么说,记住Joel Test,但是在我想要的任何机器上,包括我自己的机器,根本不需要任何CI.这是一种令人宽慰的事情,我从那时起就没有回头,现在CI配置保持在最低限度.应用于您的案例:创建一个msbuild文件,如下所示,TC中的构建步骤调用它的Build目标,并有一个与实际项目文件相关的MyTargetProjectFile系统参数:

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

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

还有一个选择:忽略TeamCity的警告.我从来都不清楚为什么他们坚持这样做,这似乎违反直觉并导致像这样的问题:]具有不同属性的不同构建步骤似乎是一个相当基本的要求,不是吗？我不认为我们有任何msbuild步骤不使用/ p,它一切正常.