我已向 TeamCity (v8) 项目添加了一个检查 (.NET) 构建步骤，该项目包含一个针对单个虚拟 C# 类的 Visual Studio 2010 解决方案构建步骤。

如果我收到任何检查错误或警告，构建步骤的失败条件将设置为失败。

我的虚拟班级仅生成 2 个建议，但构建失败声称

“度量更改时构建失败：检查警告的数量太大：3”。

有没有办法让 TeamCity 步骤忽略建议？

我启用了调试输出，并且该步骤中肯定没有警告：

虚拟类如下：

请注意，我仍然希望在 Visual Studio 中报告建议和提示，因此不能在 ReSharper 设置中将所有非警告和错误更改为不报告（或创建和维护此类设置文件仅供 TeamCity 使用）。

描述

我们appium在运行 Mavericks 的 Apple MacMini 上的TeamCity 8cucumber套件中使用。问题是appium在登录时（通过Automator）从TeamCity运行时似乎无法与iOS模拟器交互。

我发现唯一可行的组合是Terminal在交互式会话中运行以下命令：

sh /Applications/buildagent/bin/agent.sh start

什么不起作用？

• agent.sh start从ssh会话运行
• 使用 Automator 创建一个在登录时启动的 shell 脚本（macmini 设置为自动登录）

理论

我的理论是它与Preferences -> Security & Privacy -> Accessibility. 从终端启动时它起作用的唯一方法是将终端添加到此允许的应用程序列表中。我不确定我需要添加什么到此列表中才能使其在登录时自动工作。

任何帮助将不胜感激。

I want to cancel then start my build through url:

This how I starting my build:

but when I'm trying to cancel/stop it:

I'm getting exception:

Source: Accessing server by HTTP

I tried through REST API but didn't helped me.

I try to create build configuration for automation project web deploying. Deploying from dev machine works well but there is an exception when running from TeamCity

我最近开始在我们的构建服务器上看到上述错误的频率越来越高。在此期间，我们的 TeamCity 配置没有任何变化，所以我猜可能是 GitHub 上的更改导致了错误。

我尝试将我们的 VCS 轮询间隔从 60 秒更改为 600 秒，以防 GitHub 进行某种连接限制，但没有任何影响。

是否可以让 TeamCity 对连接超时不那么敏感？

我正在尝试编写一个在 TeamCity 构建配置中创建参数的 PowerShell 脚本，这很容易使用 REST API。

只需设置一个经过身份验证的 webclient 并对构建配置的参数发出 PUT 请求：

但是这个参数包含一个密码，需要在 Team City 中存储为 Password 类型。

我知道我可以从 TeamCity 的 UI 手动更改参数的类型，但是有没有办法使用 REST API 自动执行此操作（否则我将手动执行 100 多个构建配置）

是否有 REST API 端点来获取 TeamCity 中构建待处理的更改集合？

我们将构建设置为手动，它在 TeamCity 外部触发，并希望显示该构建中的提交的项目符号列表。

在用户界面中，您可以在“Pending Changes (X)”选项卡下看到这一点。

我找不到任何这样做的例子，我发现的最接近的是：

不过，这似乎返回了最后的更改。

以前有人做过吗？

我们在 TeamCity 中有一个构建配置，包含 3 个构建步骤。有没有办法阻止第 2 步为个人构建运行，以便正常的 VCS 触发器执行第 1、2 和 3 步 - 但只有 1 和 3 为个人构建运行？

对于个人构建，有一个变量 BUILD_IS_PERSONAL 设置为 true，但如果没有，则未定义： http ://confluence.jetbrains.com/display/TCD8/Predefined+Build+Parameters

您打算如何使用该变量，因为每当我在构建配置脚本中使用它时，它都会要求我手动定义该值？

我设置了从 Windows 代理连接到 Linux 的 SSH 登录，但 TeamCity 给出了以下错误。

[新建问题] com.jcraft.jsch.JSchException: invalid privatekey: [B@5543cd

SSH Secure Shell 生成的密钥对连接服务器没有问题。

类似的问题在这里，但这不是我的程序问题，而是 teamcity 内部异常。

请注意，我的问题不是 GitHub VCS 连接问题。只是我的 Windows TeamCity 代理到 CentOS Linux 服务器之间的问题。

完整的堆栈跟踪如下。

[步骤 6/8] com.jcraft.jsch.JSchException: 无效的私钥: [B@5543cd at com.jcraft.jsch.KeyPair.load(KeyPair.java:702) at com.jcraft.jsch.KeyPair.load(KeyPair .java:542) 在 com.jcraft.jsch.IdentityFile.newInstance(IdentityFile.java:40) 在 com.jcraft.jsch.JSch.addIdentity(JSch.java:389) 在 com.jcraft.jsch.JSch.addIdentity( JSch.java:349) 在 jetbrains.buildServer.deployer.agent.ssh.SSHSessionProvider.initSessionKeyFile(SSHSessionProvider.java:110) 在 jetbrains.buildServer.deployer.agent.ssh.SSHSessionProvider.(SSHSessionProvider.java:80) 在 jetbrains。 buildServer.deployer.agent.ssh.SSHExecRunner.createBuildProcess(SSHExecRunner.java:26) 在 jetbrains.buildServer.agent.impl.runner.CallRunnerService.doCreateBuildProcess(CallRunnerService.java:71) 在 jetbrains.buildServer.agent.impl.runner。 CallRunnerService.createBuildProcess(CallRunnerService.java:47) 在 jetbrains.buildServer.agent.impl.buildStages.runnerStages.start.CallRunnerStage.doBuildStage(CallRunnerStage.java:47) 在 jetbrains.buildServer.agent.impl.buildStages.RunnerStagesExecutor$1.callStage(RunnerStagesExecutor.java:25) 在jetbrains.buildServer.agent.impl.buildStages.RunnerStagesExecutor$1.callStage(RunnerStagesExecutor.java:18) at jetbrains.buildServer.agent.impl.buildStages.StagesExecutor.callRunStage(StagesExecutor.java:78) at jetbrains.buildServer.agent.impl .buildStages.StagesExecutor.doStages(StagesExecutor.java:37) 在 jetbrains.buildServer.agent.impl.buildStages.RunnerStagesExecutor.doStages(RunnerStagesExecutor.java:18) 在 jetbrains.buildServer.agent.impl.buildStages.startStages.steps.RunnerContextExecutor .callRunnerStages(RunnerContextExecutor.java:43) 在 jetbrains.buildServer.agent.impl.buildStages.startStages.steps。StepExecutor.processNextStep(StepExecutor.java:25) 在 jetbrains.buildServer.agent.impl.buildStages.startStages.steps.ForEachBuildRunnerStage.executeRunnerStep(ForEachBuildRunnerStage.java:138) 在 jetbrains.buildServer.agent.impl.buildStages.startStages.steps。在 jetbrains.buildServer.agent.impl.buildStages.startStages.steps.ForEachBuildRunnerStage.executeBuildRunners(ForEachBuildRunnerStage.java:83) 在 jetbrains.buildServer.agent.impl.buildStages.startStages.steps 的 ForEachBuildRunnerStage.runStep(ForEachBuildRunnerStage.java:123)。 ForEachBuildRunnerStage.doBuildStage(ForEachBuildRunnerStage.java:44) at jetbrains.buildServer.agent.impl.buildStages.BuildStagesExecutor$1.callStage(BuildStagesExecutor.java:31) at jetbrains.buildServer.agent.impl.buildStages.BuildStagesExecutor$1.callStage(BuildStagesExecutor. java:24) 在 jetbrains.buildServer.agent.impl。buildStages.StagesExecutor.callRunStage(StagesExecutor.java:78) at jetbrains.buildServer.agent.impl.buildStages.StagesExecutor.doStages(StagesExecutor.java:37) at jetbrains.buildServer.agent.impl.buildStages.BuildStagesExecutor.doStages(BuildStagesExecutor. java:24) 在 jetbrains.buildServer.agent.impl.BuildRunAction.doStages(BuildRunAction.java:70) 在 jetbrains.buildServer.agent.impl.BuildRunAction.runBuild(BuildRunAction.java:50) 在 jetbrains.buildServer.agent.impl .BuildAgentImpl.doActualBuild(BuildAgentImpl.java:263) at jetbrains.buildServer.agent.impl.BuildAgentImpl.access$100(BuildAgentImpl.java:50) at jetbrains.buildServer.agent.impl.BuildAgentImpl$1.run(BuildAgentImpl.java:236 ) 在 java.lang.Thread.run(Thread.java:744)doStages(StagesExecutor.java:37) 在 jetbrains.buildServer.agent.impl.buildStages.BuildStagesExecutor.doStages(BuildStagesExecutor.java:24) 在 jetbrains.buildServer.agent.impl.BuildRunAction.doStages(BuildRunAction.java:70) 在 jetbrains .buildServer.agent.impl.BuildRunAction.runBuild(BuildRunAction.java:50) 在 jetbrains.buildServer.agent.impl.BuildAgentImpl.doActualBuild(BuildAgentImpl.java:263) 在 jetbrains.buildServer.agent.impl.BuildAgentImpl.access$100( BuildAgentImpl.java:50) 在 jetbrains.buildServer.agent.impl.BuildAgentImpl$1.run(BuildAgentImpl.java:236) 在 java.lang.Thread.run(Thread.java:744)doStages(StagesExecutor.java:37) 在 jetbrains.buildServer.agent.impl.buildStages.BuildStagesExecutor.doStages(BuildStagesExecutor.java:24) 在 jetbrains.buildServer.agent.impl.BuildRunAction.doStages(BuildRunAction.java:70) 在 jetbrains .buildServer.agent.impl.BuildRunAction.runBuild(BuildRunAction.java:50) 在 jetbrains.buildServer.agent.impl.BuildAgentImpl.doActualBuild(BuildAgentImpl.java:263) 在 jetbrains.buildServer.agent.impl.BuildAgentImpl.access$100( BuildAgentImpl.java:50) 在 jetbrains.buildServer.agent.impl.BuildAgentImpl$1.run(BuildAgentImpl.java:236) 在 java.lang.Thread.run(Thread.java:744)impl.BuildRunAction.runBuild(BuildRunAction.java:50) at jetbrains.buildServer.agent.impl.BuildAgentImpl.doActualBuild(BuildAgentImpl.java:263) at jetbrains.buildServer.agent.impl.BuildAgentImpl.access$100(BuildAgentImpl.java:50 ) 在 jetbrains.buildServer.agent.impl.BuildAgentImpl$1.run(BuildAgentImpl.java:236) 在 java.lang.Thread.run(Thread.java:744)impl.BuildRunAction.runBuild(BuildRunAction.java:50) at jetbrains.buildServer.agent.impl.BuildAgentImpl.doActualBuild(BuildAgentImpl.java:263) at jetbrains.buildServer.agent.impl.BuildAgentImpl.access$100(BuildAgentImpl.java:50 ) 在 jetbrains.buildServer.agent.impl.BuildAgentImpl$1.run(BuildAgentImpl.java:236) 在 java.lang.Thread.run(Thread.java:744)

我有一个 TeamCity 构建配置，直到最近它一直运行良好。突然，有一个构建卡在队列中，说它与任何代理都不兼容。给出的理由是：

隐式要求：在参数：BuildFormatSpecification 中定义的 teamcity.build.branch

我的 BuildFormatSpecification 参数是这样定义的：

%MajorVersion%.%MinorVersion%.%PatchVersion%-%teamcity.build.branch%

这又在 Build Number Format 字段中与构建计数器一起使用，如下所示：

%BuildFormatSpecification%.%sharedBuildNumber.id4%

这个想法是内部版本号像“1.0.0-develop.22”一样出现，包括正在构建的 Git 分支。这遵循语义版本控制的规则。这个方案在很多项目中都对我有用，但是突然间这个构建被卡住了，我不知道为什么。

有任何想法吗？