在构建步骤和构建配置中保留版本号
我正在使用 TeamCity 6.5.4，并且我需要为同一部署包提供 3 个构建配置。我想在所有三个构建配置中保留版本号，并能够使用该版本号来对程序集进行版本控制、标记 vcs、对 nuspec 文件进行版本控制等。
以下是配置和所需的版本号：
Configuration | Version
-------------------|---------
CI/Nightly Build | 1.1.*
Minor Release | 1.*.0
Major Release | *.0.0
TeamCity 似乎使用每个配置都有一个单独的构建增量器。这意味着每次我们发布主要或次要版本时，我都必须手动更新所有后续配置中的持久值 (1)。我是一名程序员，而且我很懒。我想要一个按钮来为我完成所有事情。
我见过通过具有依赖快照的配置的构建步骤来持久化构建号的示例，但这仅适用于相同的配置。
每次您引用 ID 时，自动增量插件都会增加数字。这对于不断变化的数字 (*) 来说很好，但对于引用持久值 (1) 来说不太好。
TeamCity 有没有办法（无论是本机还是通过插件）允许我将该版本读取并写入到可以跨构建配置保留的文件或变量？
I'm using TeamCity 6.5.4 and I need to have 3 build configurations for the same deployment package. I'd like to persist the version number across all three build configurations and be able to use that number to version the assembly, tag vcs, version the nuspec file, etc.
Here are the configurations and desired version numbers:
Configuration | Version
-------------------|---------
CI/Nightly Build | 1.1.*
Minor Release | 1.*.0
Major Release | *.0.0
It seems that TeamCity uses a separate build incrementer for each configuration. This means every time we have a major or minor release, I'd have to manually update the persisted values (1) in all of the subsequent configurations. I'm a programmer and I'm lazy. I want a single button to do everything for me.
I've seen examples of persisting the build number through build steps of a configuration with dependent snapshots, but that only works in the same configuration.
The Autoincrementer plugin bumps up the number every time you reference the ID. This is fine for the changing numbers (*), but not so good for referencing the persisted values (1).
Is there a way for TeamCity, either natively or via plugin, to allow me to read and write that version to a file or variable that can be persisted across build configurations?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可以使用
dep.btx.build.number引用依赖（工件/快照）配置的内部版本号，其中btx是 bt id后者。获得内部版本号后，将内部版本号传递给在配置中运行的脚本，解析脚本中的内部版本号并发送 服务消息从脚本发送到 Teamcity，以按照您想要的方式设置内部版本号。将此解析和设置数字作为脚本的第一步/构建步骤的第一步。You can reference the build number of the dependent ( artifact / snapshot) configuration using
dep.btx.build.numberwherebtxis the bt id of the latter. Once you have the build number, pass the build number to your script running in the configuration, parse the build number in the script and send service messages from the script to Teamcity to set the build number in the way you want. Do this parsing and setting number as the first step in your script / first step in the build steps.感谢您的建议。我选择编写一组自定义目标与我的 MSBuild 脚本一起使用，该脚本在远程 xml“清单”文件中维护程序集元数据。创建新的 TeamCity 项目时，我的构建脚本会调用 Init 目标，该目标从未填充的模板创建新的清单文件。
我使用 MSBuild 扩展包从清单文件中读取版本信息等属性。
我将 TeamCity 构建配置分为 CI、测试、次要版本和主要版本，并分别触发不同的事件。从项目构建脚本中的相应目标中，我将一个新目标添加到 DependsOnTargets 属性中，以调用自定义目标来更新适当的版本号并将其保存到清单文件中。
自定义目标中用于处理版本更新的代码：
此文件处理版本和其他元数据的持久性，从而忽略 TeamCity 内部版本号。由于 XML 元数据文件是集中式的，我可以使用这些值来填充 Nuspec、AssemblyInfo 和 WiX Installer 元数据，并通过服务消息将版本和其他相关信息传递回 TeamCity。
我添加了一个简单的 MVC Web 界面，以便我的团队可以在包详细信息发生更改时远程编辑文件内容。现在，我们有一个地方可以更新给定构建项目的版权信息和任何其他元数据等信息。我还可以让非开发人员访问 MVC 站点来更新品牌信息，而无需允许他们访问我的 TeamCity 构建配置。
除了用于将版本中继到 TeamCity 的服务消息之外，这里与 TeamCity 耦合的内容很少。我喜欢将自定义目标和构建脚本中的功能从 TeamCity 中删除，以防万一我们转向另一个构建管理解决方案。因此，我不打算花时间构建 TeamCity 插件，但可能很快就会推出一个博客系列。
我很乐意为任何感兴趣的人提供更多代码和进一步的解释。
Thanks for the suggestions. I opted to write a set of custom targets to use with my MSBuild script which maintains assembly metadata in a remote xml "manifest" file. When a new TeamCity project is created, my build script calls an Init target which creates a new manifest file from an unpopulated template.
I'm using the MSBuild Extentions pack to read attributes like version information from the manifest file.
I have my TeamCity build configurations separated to CI, Test, Minor Release, and Major Release with different events triggering each. From the corresponding target in my project build script, I add a new target to
DependsOnTargetsattribute to call the custom target to update the appropriate version number and save it to the manifest file.The code in the custom target to handle the version update:
This file handles persistence of the version and other metadata thus ignoring the TeamCity build number. Since the XML metadata file is centralized, I can use the values to populate my Nuspec, AssemblyInfo, and WiX Installer metadata as well as pass the version and other pertinent information back to TeamCity through service messages.
I added a simple MVC web interface to allow my team to edit the file contents remotely if package details change. Now we have one single place to update things like Copyright information and any other metadata for a given build project. I can also give non-dev folks access to the MVC site to update branding information without allowing them access to my TeamCity build configurations.
With the exception of the service messages used to relay version to TeamCity, there's very little here that's coupled with TeamCity. I like having the functionality in custom targets and build scripts removed from TeamCity on the off chance we move to another build management solution. For that reason, I don't envision taking time to build a TeamCity plugin, but there could be a blog series coming soon.
I'll be happy to provide more code and further explanation to anyone interested.
是的，您可以创建一个插件来轻松完成此操作。您可以采用我的自动增量构建号（跨配置）插件并修改它以满足您的需要。内部版本号将保存在一个文本文件中，该文件可通过 TeamCity 的管理屏幕进行配置。
http://github.com/ornatwork/tc_plugins/tree/master/unique
如果需要，您可以联系我询问如何更改它。
Yes, you can create a plugin to do this easy. You can take my auto increment build number ( across configurations ) plugin and modify it to fit your need. The build number will be saved in a text file that is configurable from the admin screen in TeamCity.
http://github.com/ornatwork/tc_plugins/tree/master/unique
You can hit me up for input how to change it if you need.