在 TFS2015 构建名称中使用 SourceVersion 和 rev:r [英] Using SourceVersion and rev:r in TFS2015 build names
问题描述
我们对 XAML 构建制定了一个流程，该流程在单个构建的名称中使用了 TFS 更改集编号.我们正在尝试将其中一些构建转换为 TFS 2015 上的新构建系统，但遇到了将更改设置为构建名称的问题.
We have a process we worked out with our XAML builds that used the TFS change set number in the name of the individual builds. We are trying to convert some of these builds to the new build system on TFS 2015 and running into issues getting change set into the build name.
如果我们在构建定义的构建编号格式字段中使用 $(Build.SourceVersion)$(Rev:.r)，我们会在触发构建上得到 C12345.1 的输出，但随后 .1 在手动排队的构建中.我们希望看到 C12345.2.许多研究归结为，必须在构建排队时手动输入 $(Build.SourceVersion) 以便在计算构建号时填充它.
If we use $(Build.SourceVersion)$(Rev:.r) in the Build Number Format field of the build definition, we get an output of C12345.1 on a triggered build, but then .1 on a manually queued build. We would expect to see C12345.2. Lots of research boils down to, $(Build.SourceVersion) has to be manually entered when the build is queued in order for it to be populated when the Build Number is calculated.
好的，所以我们使用 PowerShell 尝试操作内部版本号.进入 PowerShell 任务后，Build.SourceVersion 将填充正确的值.我们尝试将定义的内部版本号格式设为 $(rev:r)，这允许我们在 PowerShell 中获取它，将其与源版本值结合，并使用结果通过日志命令更新内部版本号 <代码>写入主机##vso[build.updatebuildnumber]"$buildVersion.这为我们提供了触发和手动构建的 12345.1 输出，但 rev:r 永远不会增加，因为在计算时没有与构建编号格式中找到的模式匹配的构建.因此，手动对构建进行排队最终会得到任意数量的具有完全相同名称的构建.
Ok, so we dropped into PowerShell to try to manipulate the build numbers. Once in the PowerShell task, Build.SourceVersion is populated with the correct value. We tried having the Build Number Format of the definition just be $(rev:r), which allowed us to get it in PowerShell, combined it with the Source Version value, and using the result to update the build number via the logging command Write-Host "##vso[build.updatebuildnumber]"$buildVersion. This gives us an output of 12345.1 on both the triggered and manual builds, but rev:r never increments, since there are no builds matching the pattern found in the Build Number Format at the time it is calculated. So manually queuing the builds ends up with any number of them that have the exact same name.
有没有人有获取构建名称的方法，该名称可靠地包含源版本和修订值，其中触发和手动构建的所有内容都正确递增?
Does anyone have a recipe for getting a build name that reliably contains the Source Version and Revision values where everything increments correctly for both triggered and manual builds?
推荐答案
所以经过大量的研究和试验 &错误这是我们最接近我们想要的输出...
So after much research and trial & error this is the closest we managed to come to our desired output...
- Build number 格式在配置中设置为
$(Build.SourceVersion).$(Build.BuildId). - 我们使用 powershell 脚本来解析程序集文件、源版本和构建 ID，以
Major.Minor.ChangeSet.BuildId的形式提供完整的 4 部分版本号. - 我们使用
Write-Host "##vso[build.updatebuildnumber]"$buildNumber 将此新版本号推送回我们的内部版本号 - 我们还使用 Assembly Info 步骤将这个计算出的版本号推送回实际构建过程，以便 DLL 与构建版本具有相同的版本号.
- The Build number format is set to
$(Build.SourceVersion).$(Build.BuildId)in the configuration. - We use a powershell script to parse the Assembly File, Source Version, and Build Id to come up with a full 4 part version number in the form of
Major.Minor.ChangeSet.BuildId. - We push this new version number back to our build number using
Write-Host "##vso[build.updatebuildnumber]"$buildNumber - We also used the Assembly Info step to push this calculated version number back to the actual build process, so that the DLLs come out with the same version number as the build.
这为我们提供了每个构建唯一的版本号，并指向源的特定特定状态，这是优先级.我们失去的是随着每次更改而重置的漂亮递增的内部版本号.相反，我们有一个数字，它会随着系统中任何地方发生的每次构建而递增，并且永远不会重置.
This gets us a version number that is unique for each build, and points back to specific a particular state of the source, which was the priority. What we lose is the nicely incrementing build numbers that reset with each change. Instead we have a number that increments for every build that occurs anywhere in the system, and never resets.
这篇关于在 TFS2015 构建名称中使用 SourceVersion 和 rev:r的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
