当另一个在 TFS 2008 中成功完成时触发构建
这是我习惯于 TeamCity 的一项功能 - 我可以指定某个构建配置将由另一个构建配置的成功触发。
我什至可以将一个构建的结果传递给另一个构建 - 但也许这要求太多了。
我正在 TFS2008 中寻找类似的功能,是否有一种方法可以在构建配置上设置触发器,使其在另一个成功完成后启动?
This is a feature I'm used to from TeamCity - I could specify that a certain build configuration will be triggered by the success of another build configuration.
I could even pass the results of one build to another - but perhaps this is asking too much.
I'm looking for a similar functionality in TFS2008, is there a way to set a trigger on a build configuration that it shall start after another finished successfully?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我在 TFSBuild.proj 中使用以下目标:
将新目标注入构建过程。如果成功创建了“drop”,我们只会触发依赖构建:
创建一个项目组,其中包含我们要触发的依赖构建的列表(包含属性将列出依赖构建的名称)出现在构建资源管理器中 - 在下面的例子中,依赖构建称为“集成”)。在我们的构建过程中,我们有时想要触发多个构建,并且我们希望将下一个构建指向当前构建生成的二进制文件(在本示例中,我想针对生成的二进制文件运行集成测试)。请注意绕过配置名称中的空格的黑客行为 - 例如“任何 CPU”将导致 MsBuild 参数出现问题。使用这种格式,我们可以为每个依赖构建自定义 MSBuild 参数。
现在,触发构建。请注意,我们使用自定义 GetOption:我们希望确保依赖构建使用当前构建使用的相同变更集 - 我们不能使用最新版本,因为有人可能同时签入 - 因此我们希望所有依赖构建都加入我们的“链”都基于相同的变更集。实际的命令在 Exec 中,BuildStep 的内容是确保我们报告 Exec 的成功(或失败)。
我希望这有帮助...
I use the following target in my TFSBuild.proj:
Inject the new targets into the build process. We only trigger dependent builds if a "drop" was successfully created:
Create a itemgroup that contains a list of the dependent builds we want to trigger (the Include attribute will list the name of the dependent build as it appears in the build explorer - in my case below, the dependant build is called "Integration"). In our build process, we sometimes want to trigger more than one build, and we want to point the next build at the binaries that were produced by the current build (in this example, I want to run Integration tests against the binaries produced). Notice the hack to get around spaces in configuration names - eg "Any CPU" will cause a problem in the MsBuild args. Using this format, we can have custom MSBuild args per dependent build.
Now, trigger the builds. Notice that we use a Custom GetOption: we want to make sure that dependent builds use the same changeset that the current build used - we can't use Latest, cos someone may have checked in in the meantime - so we want all dependent builds in our "chain" to all be based of the same changeset. The actual command is within the Exec, and the BuildStep stuff is to make sure we report the success (or failure) of the Exec.
I hope that helps...