Teamcity 只触发一个分支的标签
Teamcity only trigger tags from one branch
我的团队在 CI 中使用 TeamCity，我对它有点陌生。
我们正在使用 git 标签来帮助进行版本控制，但是我遇到了一个问题。
到目前为止，我设法做到了，当创建新标签时，TeamCity 触发器中的构建，但问题是它会触发任何分支和任何标签。
有没有办法让构建仅在 SPECIFIC BRANCH 上创建 TAGS 时触发？
我只希望在 master 分支上创建标签时触发构建。
感谢您的帮助。
Git 中作为对象的标签不绑定到任何特定分支 - 它们只是指向某些修订版。标签甚至可以指向那些不属于任何分支的修订（分离的 HEAD）。因此，我怀疑TeamCity判断是否在分支中创建Git标签以进行监控在技术上具有挑战性。
但是，您可以通过为 Git 标签建立一些命名规则来解决这个问题。例如，在 master 分支上创建的标签应称为 release/something 或 main/something。在这种情况下，Branch specification 字段中的值可以缩小到 +:refs/tags/release/*.
为分支的任何提交触发构建通常比以这种方式使用标签更简单。例如，在 gitflow 中，对 master 的唯一提交应该是代表新版本的合并，因此如果您使用该约定，您可以简单地监视 master 以触发构建。
如果你想使用标签，其实有两种选择。
正如 Yan Sklyarenko 所建议的，简单的选择是在标签上使用命名约定。当然，有人可能将错误的标签放在错误的位置，这要么是一个功能（它很灵活），要么是一个错误（错误导致生产构建浪费）。那里有一个 "hidden magic" 的元素。但这至少是一个易于实现的选项。
直接或多或少地做你所要求的更难的方法是在任何标签上触发构建，然后包括一个构建步骤，除非发现该标签是 "on the master branch".
现在我将 "on the master branch" 放在引号中，因为正如 Sklyarenko 先生指出的那样，它对 git 中的分支和标签的结构方式有些松散。真的，您会说，您想了解 "on commits reachable from master" 的新标签。事实上，您的意思可能是 "reachable from master using first-parent pointers only"。也就是说
D
/ \
A -- B - E -- F <--(master)
\
C <--(branch)
如果我们标记 C，则无法从 master 访问。 （"Reachable" 表示通过父指针，因此您只能沿着图表上向左的线。）
D 可从 master 访问，但如果完成 "normally" D 是 E 的第二个父级。因此，如果我们说 "reachable by first-parent pointers"，则 A、B、E 和 F 符合条件 - 这可能就是您所说的 "on master" 的意思。
我知道在 TC 中进行这种检查的唯一方法是使用脚本化构建步骤；那么你需要一个 git 命令来提供信息，这个标签是否符合标准？你可以使用这个：
git rev-list --first-parent master |grep -q $(git rev-parse <tagname>)
（其中 <tagname> 是标签的名称）它将 return 0 当且仅当标签满足条件。
鉴于您使用标签的方式，您可能还想检查相关标签是否是 master 上的最新标签。也就是说，如果你有
A -- B -- C -- D <--(master)
^
tag-1.0
如果有人标记 D，您可能只想构建 ，而不是他们标记 A、B 或 [=21] =]（因为您在 C 已经有一个标签）。在这种情况下，您可以检查是否
git describe --tags --first-parent --abbrev=0 master
return是您的新标签的名称。
我的团队在 CI 中使用 TeamCity，我对它有点陌生。
我们正在使用 git 标签来帮助进行版本控制，但是我遇到了一个问题。
到目前为止，我设法做到了，当创建新标签时，TeamCity 触发器中的构建，但问题是它会触发任何分支和任何标签。 有没有办法让构建仅在 SPECIFIC BRANCH 上创建 TAGS 时触发？
我只希望在 master 分支上创建标签时触发构建。
感谢您的帮助。
Git 中作为对象的标签不绑定到任何特定分支 - 它们只是指向某些修订版。标签甚至可以指向那些不属于任何分支的修订（分离的 HEAD）。因此，我怀疑TeamCity判断是否在分支中创建Git标签以进行监控在技术上具有挑战性。
但是，您可以通过为 Git 标签建立一些命名规则来解决这个问题。例如，在 master 分支上创建的标签应称为 release/something 或 main/something。在这种情况下，Branch specification 字段中的值可以缩小到 +:refs/tags/release/*.
为分支的任何提交触发构建通常比以这种方式使用标签更简单。例如，在 gitflow 中，对 master 的唯一提交应该是代表新版本的合并，因此如果您使用该约定，您可以简单地监视 master 以触发构建。
如果你想使用标签，其实有两种选择。
正如 Yan Sklyarenko 所建议的，简单的选择是在标签上使用命名约定。当然，有人可能将错误的标签放在错误的位置，这要么是一个功能（它很灵活），要么是一个错误（错误导致生产构建浪费）。那里有一个 "hidden magic" 的元素。但这至少是一个易于实现的选项。
直接或多或少地做你所要求的更难的方法是在任何标签上触发构建，然后包括一个构建步骤，除非发现该标签是 "on the master branch".
现在我将 "on the master branch" 放在引号中，因为正如 Sklyarenko 先生指出的那样，它对 git 中的分支和标签的结构方式有些松散。真的，您会说，您想了解 "on commits reachable from master" 的新标签。事实上，您的意思可能是 "reachable from master using first-parent pointers only"。也就是说
D
/ \
A -- B - E -- F <--(master)
\
C <--(branch)
如果我们标记 C，则无法从 master 访问。 （"Reachable" 表示通过父指针，因此您只能沿着图表上向左的线。）
D 可从 master 访问，但如果完成 "normally" D 是 E 的第二个父级。因此，如果我们说 "reachable by first-parent pointers"，则 A、B、E 和 F 符合条件 - 这可能就是您所说的 "on master" 的意思。
我知道在 TC 中进行这种检查的唯一方法是使用脚本化构建步骤；那么你需要一个 git 命令来提供信息，这个标签是否符合标准？你可以使用这个：
git rev-list --first-parent master |grep -q $(git rev-parse <tagname>)
（其中 <tagname> 是标签的名称）它将 return 0 当且仅当标签满足条件。
鉴于您使用标签的方式，您可能还想检查相关标签是否是 master 上的最新标签。也就是说，如果你有
A -- B -- C -- D <--(master)
^
tag-1.0
如果有人标记 D，您可能只想构建 ，而不是他们标记 A、B 或 [=21] =]（因为您在 C 已经有一个标签）。在这种情况下，您可以检查是否
git describe --tags --first-parent --abbrev=0 master
return是您的新标签的名称。