TeamCity 2020.1ヘルプ

既知の問題

このページには、TeamCityの既知の課題に対する回避策のリストが含まれています。

To see issues specific to particular versions of TeamCity, go to the respective section.

JDK 8アップデート242+との非互換性

JDK 8u242 +で実行されている2019.2.1までのTeamCityバージョンは、Git操作またはWindowsドメイン認証操作などで java.lang.NoClassDefFoundError: Could not initialize class XXX エラーを報告できます。

TeamCity 2019.2.2がリリースされるまで、TeamCityサーバーにはJava 8u232バージョンを使用することをお勧めします。

Windowsサービスとして実行されているエージェント

When a TeamCity build agent is installed as a Windows service, there may appear various "Permission denied" or "Access denied" errors during the build process, see details below.

セキュリティ関連の課題

The user account used by the service is required to have sufficient permissions to perform the build and manage the service. If you run the TeamCity agent service under the SYSTEM account, do the following:

  1. 必要な権限が付与された通常のユーザーアカウント用の変更 SYSTEM。

  2. サービスを再開してください。

Windowsサービスの制限

Windowsサービスとして、TeamCityエージェントとビルドプロセスはネットワーク共有とマップされたドライブにアクセスできません。

To overcome these restrictions, run TeamCity agent via console.

自動GUIおよびブラウザテストの課題

これらの課題には、ヘッドレステストの実行エラー、TeamCityエージェントとWindowsデスクトップとの相互作用の課題などが含まれます。

これらを解決/回避するには

  1. Run TeamCity agent via console.

  2. デスクトップをロックするスクリーンセーバーを起動しないようにビルドエージェントマシンを設定します。

  3. Configure the TeamCity agent to start automatically (for example, configure an automatic user logon on Windows start and then configure the TeamCity agent start (via agent.bat start) on the user logon).

グラフィカルテストの場合、ビルドエージェントをサービスとして開始することはできません。ユーザーの自動ログオン後1分遅れてビルドエージェントの起動を構成することをお勧めします。タスクスケジューラで bin\agent.bat start コマンドを使用し、そこで遅延を構成します。

自動GUIテストの実行とRDPの使用

RDPはセッションのためにマシンのビデオカードからのものをオーバーライドするそれ自身のビデオドライバを使用します。セッションをコンソールにリダイレクトすると、Windowsのグラフィカルドライバがアンロードされます。これは、テストの前にビルド構成に次の手順を追加することで実行できます(以下の例はPowerShell用ですが、他の言語(DOS、Python)も使用できます)。

$sessionInfo=((quser $env:USERNAME | select -Skip 1) -split '\s+') if ($sessionInfo[1] -like "rdp-tcp*") { tscon $sessionInfo[2] /dest:console }

where " quser [current username] " lists all the connections to that machine for the user, either console or graphical.
The one listed as rdp-tcp#* is the remote desktop connection which can be redirected to the console using " tscon [connection id] /dest:console ".

.NET Seleniumの課題

When a TeamCity agent is started as a Windows service and automated tests for .NET applications use Selenium WebDriver, the tests may fail due to browser drivers limitations. As a solution, consider starting the agent manually.

他のリソースが初期化される前のサービスの早期開始

To handle this, consider using the 自動 (遅れたスタート) option of the service settings or configure service dependencies(英語).

詳しい調査手順については、よくある問題のページを参照してください。

java.lang.OutOfMemoryError:新しいネイティブスレッドエラーを作成できません

If your TeamCity server is running on SUSE® Linux Enterprise (or using systemd Daemon), the java.lang.OutOfMemoryError:新しいネイティブスレッドエラーを作成できません may be caused by the cgroup process number controller(英語) feature limiting the number of processes and the amount of threads in a cgroup to 512 by default.

制限を大きくすると(TeamCityサーバーの4096など)、課題は解決します。

See also this external posting(英語).

ブラウザキャッシュの消去

There is a web UI-related issue which some our users have encountered (and it cannot be reproduced on other computers) which is tied to the cached versions of content. If you have come across such problem, make sure your browser does not use cached versions of content by clearing browser caches(英語).

テストでLog4jを使ってロギングする

テストでLog4jロギングを使用していると、場合によってはLog4jの出力がログから失われることがあります。そのような場合は、次の手順に従ってください。

  • Log4j 1.2.12を使用

  • Log4j 1.2.13+の場合、Log4j構成で使用されるコンソールアペンダに "Follow=true" パラメータを追加します。

    <appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender"> <param name="Follow" value="true"/> </appender>

エージェントサービスは、Windows x64でのユーザーログアウトで終了できます。

使用されているバージョンのJavaサービスラッパー(英語)はWindows 64を完全にはサポートしていないため、ユーザーのログアウト時にエージェントランチャープロセスが強制終了されます。エージェント自体は、次回の再起動(サーバーのアップグレードまたはエージェントのプロパティの変更)まで機能します。

失敗したビルドは、Maven 2.0.7で成功したものとして報告できます

This is a known bug in this version of Maven. Consider using any later version.
In case it's not possible, you can patch mvn.bat yourself by replacing the fragment at line 148 of mvn.bat :

:error set ERROR_CODE=1

次のように:

:error if "%OS%"=="Windows_NT" @endlocal set ERROR_CODE=1

矛盾するソフトウェア

Most common indicators of conflicting software are errors like "Access is denied", "Permission denied" or java.io.FileNotFoundException mentioning the file that is present and is writable by the user the agent/build runs under. Also, certain software running in background (like antiviruses) can significantly slow down build agent operations like sources checkout, artifact publishing or even build running.

Certain antivirus software like Kaspersky Internet Security can result in Java process crashes or other misbehavior like inability to access files. For example, see the issue(英語).

ESETアンチウイルスはAnt / IntelliJ IDEAプロジェクトを遅くすることもできます(エージェント上のlocalhostへのTCP接続を遅くする)。

TeamCityサーバーまたはエージェントマシンでウイルス対策を実行し、ディスクアクセスエラーが発生したり、パフォーマンスが低下したりする場合は、課題を調査してJetBrainsに報告する前に、ウイルス対策ソフトウェアを無効にするか完全にアンインストールします。

TeamCityサーバーホーム全体とTeamCityデータディレクトリをバックグラウンドチェックから除外し、既知のメンテナンスウィンドウで定期的なチェックを実行して、サーバーのパフォーマンスに大きな影響を与えないようにすることをお勧めします。TeamCityエージェントでは、バックグラウンドチェックからTeamCityエージェントホームを除外することをお勧めします。

There might be problems with the Windows Indexing Service, so disable various indexing services. See the related issue(英語) for more details. Windows System Restore Feature might also need disabling.

WinCVS、TortoiseCVS、TortoiseSVN、およびその他のTortoise *製品のようなバックグラウンドインデックス付きのソフトウェアをインストールしないでください。これはサーバーに適用され、エージェント側のチェックアウトを使用する場合はエージェントにも適用されます。

Skypeソフトウェアは、以下のことが知られています。

  • システムのポート80を使用すると、デフォルトのポート80ではTeamCityサーバーを利用できない可能性があります。

  • Internet Explorerに表示されるページのレイアウトが正しくありません。Internet ExplorerのSkypeプラグインは非難することです。(TW-13052(英語)

Subversionの課題

SVN: E175002: 致命的なアラートを受信: bad_record_mac

Add a system property -Dsvnkit.http.sslProtocols=SSLv3,TLS on the build server (see TeamCityサーバー起動プロパティの設定 ).
If you use checkout on agent, add this property on build agent as well.

Subversion関連のJVMクラッシュ

SVN関連のコード(org.tmatesoft.svnパッケージなど)の実行中にJVMがクラッシュした場合は、次のいずれかの方法で無効にすることができます。

  • クラッシュしたプロセスに -Dsvnkit.useJNA=false JVMオプションを渡す (サーバーまたはエージェント)

  • Making NTLM support less prioritative by passing the -Dsvnkit.http.methods=Basic,Digest,NTLM JVM option.
    Anyway, upgrading the JVM used to the latest available version(英語) is recommended.

NUnit 2.4.6のパフォーマンス

NUnit 2.4.6の課題により、そのパフォーマンスはNUnit 2.4.1より遅くなるかもしれません。追加情報については、当社の課題トラッカーの該当する課題を参照してください。TW-4709(英語)

StarTeamの性能

TeamCityサーバーでStarTeam SDK 9.3の代わりにStarTeam SDK 9.0を使用すると、TeamCityサーバーとStarTeamサーバー間の接続が遅い場合に、VCSのパフォーマンスが大幅に向上します。

WindowsでのPerforce 2009.2パフォーマンス

If you run Perforce 2009.2 on Windows you may experience significant slow down. This is an issue with P4 server running on Windows. Refer to corresponding section(英語) in Perforce documentation.

ビルドスケジュールされたトリガーの間違った時間 (タイムゾーンの課題)

プラットフォームで利用可能な最新のJava 8インストール用アップデート(たとえばOpenZDK 8 by Amazon Corretto(英語))を使うようにしてください。

IntelliJ IDEAをアップグレードすると、事前にテストされたアクティブなコミットに影響を与える可能性があります

IntelliJ IDEA X(または他のIntelliJ Xプラットフォーム製品)にアップグレードする前に、アクティブな事前テスト済みコミットがないことを確認してください。そうしないと、アップグレード後にコミットできなくなります。これは、ディレクトリベースのIDEAプロジェクトを使用する場合にのみ関係します(プロジェクトファイルは .idea ディレクトリに格納されています)。

同じサーバー上で実行されている他のJavaアプリケーション

同じホスト名で他のWebアプリケーションが利用可能な場合は、セッションCookieの競合が発生する可能性があります。これは通常、ランダムなユーザーのログアウトやセッションレベルのデータの消失によって見えます。(例:TW-12654(英語))これを解決するために、アプリケーションにアクセスするときに異なるホスト名を使用できます。

データベースが使用中であると主張してサーバーが起動しない

1つのTeamCityサーバーのみが1つのデータベースを処理できます。これはTeamCityサーバーの起動時にチェックされます。

" The Database is in Use " error on the start-up is reported in either of the following cases:

  • 同じデータベースに接続されている複数のTeamCityサーバーを始動しようとしました

  • 2番目のTeamCityインスタンスが検出された

  • 内部HSQLデータベースが別のアプリケーションによって使用されています

The error is most probably caused by the fact that there is another running TeamCity installation which is connected to the same database. Сheck that the database properties are correct and there is no other TeamCity server using the same database.

TeamCity 8.0以前、すべての設定が正しい場合、TeamCityサーバーまたはデータベースサーバーが誤ってシャットダウンされたときにエラーが発生する可能性があります。解決方法はデータベースの種類によって異なります。

  • MySQL : MySQLサーバーを再起動してからTeamCityを再起動します。

  • PostgreSQLOracleMS SQL:誤ってシャットダウンしたTeamCityから接続を強制終了してから、再度TeamCityを起動します。

  • 内部データベース(HSQL):<TeamCityホーム> \ systemディレクトリから buildserver.lck ファイルを削除してから、TeamCityをもう一度起動します。

TeamCityサーバーからのダウンロードが遅い

TeamCityからアーティファクトをダウンロードするときに速度が遅い場合は、localhostからダウンロードしてサーバーマシンで速度を確認してください。localhostの速度が課題ない場合、TeamCity(Tomcat)設定と組み合わせると、課題はネットワーク構成またはOS /ハードウェア設定にある可能性があります。

Make sure < TeamCityホーム >\conf\server.xml file corresponds to the file included in TeamCity distribution (can be checked in .tar.gz distribution). If you have the following "Connector" node (ports numbers can be different):

<Connector port="8111" protocol="HTTP/1.1" connectionTimeout="60000" redirectPort="8543" useBodyEncodingForURI="true" />

それをに変更します。

<Connector port="8111" protocol="org.apache.coyote.http11.Http11NioProtocol" connectionTimeout="60000" redirectPort="8543" useBodyEncodingForURI="true" socket.txBufSize="64000" socket.rxBufSize="64000" tcpNoDelay="1" />

TeamCityサーバーを再起動します。

これがダウンロード速度を助けない場合、ケースを調査するために、ケースを調査するために適切なネットワーク関連課題調査スキルを持つ管理者を見つける必要があるかもしれません。

IISリバースプロキシの背後にあるサーバーにアーティファクトを公開できない

この問題は、ビルドサーバーとエージェント間のIISリバースプロキシを含む構成にのみ関係します。ビルドアーティファクトをサーバーに公開しようとしているビルドエージェントが無限ループで見つかることがあります。ビルドログは次のようになります。

[11:15:05]Publishing artifacts [11:15:05][Publishing artifacts] Collecting files to publish: [toZip/** => artifact.zip] [11:15:06][Publishing artifacts] Creating archive artifact.zip (9s) [11:15:06][Creating archive artifact.zip] Creating C:\BuildAgent\temp\buildTmp\ZipPreprocessor2847146024236637664\artifact.zip [11:15:15][Creating archive artifact.zip] Archive was created, file size 32142324 bytes [11:15:15][Publishing artifacts] Sending toZip/** [11:15:25][Publishing artifacts] Sending toZip/** [11:15:39][Publishing artifacts] Sending toZip/** [11:15:48][Publishing artifacts] Sending toZip/** [11:16:01][Publishing artifacts] Sending toZip/** [11:16:16][Publishing artifacts] Sending toZip/**

一方、teamcity-agent.logはIISからの404の応答でいっぱいになります。

[2012-08-01 12:04:55,514] WARN - jetbrains.buildServer.AGENT - <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/> <title>404 - File or directory not found.</title> <style type="text/css"> <!-- body{margin:0;font-size:.7em;font-family:Verdana, Arial, Helvetica, sans-serif;background:#EEEEEE;} fieldset{padding:0 15px 10px 15px;}

これの最も一般的な原因は maxAllowedContentLength 設定(IISの場合)です

  • 小さすぎる、または

  • 未設定のままで、デフォルトは30000000バイト (<30 Mb)

そのため、maxAllowedContentLength より大きいアーティファクトはIISによって破棄されます。設定値を確認して、ビルドを再実行してください。

プレリリースパッケージはTeamCity NuGetフィードに表示されません

問題 : プレリリースパッケージはTeamCity NuGetフィードに表示されません。

原因 : NuGet clients バージョン3より前 fail to list prerelease packages if the package version violates the required format(英語).

ソリューション : Delete build artifacts whose versions violate the required format(英語).

TeamCity NuGetフィードでパッケージのインデックス作成が遅い

問題 : TeamCityサーバーホストマシンをTeamCity 2017.1ビルドメタデータに移動またはアップグレードした後でリセットできます。

原因 : TeamCity NuGetフィードはビルドメタデータに依存しており、パッケージの再インデックス作成はパッケージの数とTeamCityサーバーのアイドル時間によっては多くの時間がかかります。

ソリューション : To speed up build metadata re-indexing, specify the following internal properties:

teamcity.buildIndexer.indexPackSize=1000 teamcity.buildIndexer.packSleepDurationMs=10

メタデータのインデックス作成の進行状況を確認するには、teamcity-server.logファイルで次のような行を探します。

INFO - .index.BuildIndexer (metadata) - Enqueued next 100 builds for indexing, builds left: 7064, last build id: 8142

インデックスの再作成が完了したら、これらの内部プロパティを削除します。

TeamCityからHTTPSに接続する際のSSLの問題(ハンドシェイクアラート): 認識されていない名前)

This problem may happen when changing JVM from 1.6 to 1.7 and connecting some incorrectly configured HTTPS servers. The problem and workaround for it are described in this issue(英語).

MS SQL ServerとTeamCityを接続するSSLの問題

MS SQL Serverは常にjdbcクライアント(TeamCityアプリケーション)とサーバーとの間にSSL接続を確立するため、接続の問題が発生する可能性があります(SQL例外:Connection reset)。

影響を受けるMS SQLのバージョン

Any version prior to the ones listed below:

  • SQL Server2012製品版以降

  • SQL Server2008Service Pack 3累積アップデート4

  • SQL Server 2008 R2 Service Pack 1累積アップデート6

  • SQL Server 2008R2サービスパック2

原因 : The problem is caused by the Java 1.6 update addressing this security vulnerability(英語).

ソリューション : Microsoft SQL Serverアップグレードをお勧めします。

回避策 : 何らかの理由でMicrosoft SQL Serverのアップグレードが不可能な場合は、データベース接続をSSLまたはTLSで暗号化したまま、古いバージョンのMicrosoft SQL Serverを使用するようにTeamCityを設定できます。

  • Continue using a block cipher such as AES_128_CBC or 3DES_EDE_CBC , but disable CBC protection via -Djsse.enableCBCProtection=false Java command-line option (that can be added to TEAMCITY_SERVER_OPTS environment variable, as described here. The jsse.enableCBCProtection Java system property is also available in all OpenJDK 8 versions and IBM J9 8.0.0 SR1(英語) and later. Secure connection between TeamCity and Microsoft SQL Server would be stable but still vulnerable to CVE-2011-3389(英語) also known as BEAST .

  • RC4_128などのストリーム暗号(BEASTの影響を受けにくい)にフォールバックします。これにより、接続がCVE-2015-2808(英語)に対して脆弱になります。

Try running with antivirus software uninstalled before reporting the issue to JetBrains. For example, see the issue(英語).

エージェントの再インストール中に歪んだ構成ウィンドウ

When installing a TeamCity agent via a Windowsエージェントインストーラー on top of the already installed agent with a different version of Java, the " ビルドエージェントのプロパティを構成する " installation window might appear distorted.

この課題はTeamCity 2019.1.5で修正されました

To workaround this issue without upgrading to 2019.1.5, uninstall the previously installed agent version before installing a new agent into the same directory.
To uninstall the agent, invoke Uninstall.exe in the エージェントホームディレクトリ , clear all the " 除去... " checkboxes to keep the agent logs and configuration, and click アンインストール . After the successful uninstallation, you can proceed with installing the new agent version via the agent installer.

Windows Dockerコンテナー

TeamCity Dockerコンテナーイメージに共通の問題。

  • KB4340917(英語)を使用したWindows 10バージョン1803以降、コンテナーからローカルホストへのポートマッピングを使用することが可能です。以前のWindowsバージョンでは、このマシンに関連付けられている非ローカルホストのIPアドレスに対して機能します。マシンのホスト名を使用して実行中のアプリケーションにアクセスするか、ipconfig コマンドを使用してIPアドレスを決定できます。実際には動作しますが、netstat -an コマンドではポートがどのIPアドレスでも開いていることが示されない場合があります。これはWindows上のDockerの既知の問題でもあります。

  • Windows 10では、コンテナーごとに割り当てられるメモリはデフォルトで1GBです。この値を増やすには、以下のメモリオプションを使用します。

    docker run ... -m 2GB -e TEAMCITY_SERVER_MEM_OPTS="-Xmx2g -XX:ReservedCodeCacheSize=350m"
  • Windows 10ではコンテナーはHyper-V経由で動作し、ネットワークや他のサブシステムで問題が発生する可能性があります。これらの問題を診断するには、次のPowerShellスクリプトを実行してください。

    Invoke-WebRequest https://aka.ms/Debug-ContainerHost.ps1 -UseBasicParsing | Invoke-Expression
  • When starting a TeamCity server from a Windows Docker image, make sure to grant " 認証されたユーザー " the フルコントロール over the directories used as volumes. 関連号を見る(英語)

  • When starting a Windows Docker container with the directory C:/BuildAgent/work mapped as a volume to the container host, Git for Windows fails with a following error: " 無効なパス '/ ContainerMappedDirectories': そのようなファイル、又はディレクトリはありません ". The workaround is not to add C:/BuildAgent/work as a volume.

To analyze the script output, refer to the following documents(英語). If it shows that there are problems with the container network subsystem, try resetting it using the クリーンアップスクリプト(英語)

Windows用Dockerのトラブルシューティングに関する詳細は、Docker(英語)およびマイクロソフト(英語)のドキュメントにあります。

WindowsにインストールされたDockerサーバーOSに関する情報がエージェントにない

Windows 10では、DockerサーバーはHyper-Vサービスに依存しており、その起動にはかなりの時間がかかる場合があります。この課題を解決するには、Windowsサービス用のDocker、デフォルトでは com.docker.service に依存するようにTCBuildAgent Windowsサービスを構成します。

Windows上のLinux Dockerコンテナー

TeamCity 2017.2以降、DockerラッパーはWindowsベースのコンテナーが起動されたときにWindows上で動作します。

If a Linux container is started on a Windows machine, TeamCity displays the error message "Starting Linux Docker containers under Windows is not supported. To avoid this problem, add the teamcity.agent.jvm.os.name does not contain Windows agent requirement.

DockerラッパーがWindowsプラットフォームでLinuxコンテナーを実行する場合のユースケースをサポートする必要がある場合は、TW-51820(英語)で関連するコメントに投票してください。

Windowsコンテナーの現地時間の問題

When using Windows Docker containers, there is an issue with incorrect time in Windows containers(英語) when the system time in a container goes out of sync with the time on the host machine. It could cause problems in integrations where response time is significant (for example, OAuth tokens).

この問題を解決するには、ホストマシンをWindows Server 2019 / Windows 10 1809にアップグレードし、TeamCity dockerイメージWindowsコンテナー1809と互換性(英語)があります。を使用してください。

"アクセスが拒否されました"または"パスへのアクセスが拒否されました"コンテナー起動時の問題

When Docker is starting Windows containers with process isolation, it uses a Windows user account which lacks the write access to the directory with Docker volumes. In this case, build agents may fail to start due to the " パスへのアクセスが拒否されました " or " アクセスは拒否されました " error.

To resolve this issue, grant the "Full control" permission to the "Authenticated Users" group for the %\PROGRAMDATA%\docker\volumes directory.

dotCoverの既知の課題

dotCoverはWindows Nano Serverをサポートしていません

If you try to run dotCover on an agent with the Nano Server OS, the build will fail with an exit error " コード-1073741515でプロセスが終了しました ". Instead of Nano Server, consider using サーバー・コア(英語) which is an alternative minimal installation option of Windows Server.

dotCoverはmsbuildのカバレッジ統計をサポートしていません

dotCoverは、dotnet msbuild /t:vstest コマンドのカバレッジ統計の収集をサポートしていません。代わりに dotnet test を使用してください。

テスト設定を使用したコードカバレッジ構成は廃止されました

テスト設定を使用したコードカバレッジ設定は、dotCoverで廃止されます。Microsoftドキュメントのさらに読み込む(英語)

If you use .testsettings files, TeamCity will display a warning message in the log. To prevent this issue, we suggest that you use .runsettings(英語) files instead. If, for some reason, you have to continue using .testsettings , install dotCover version 2019.1.x or earlier on TeamCity agents, as described here.

Xcode 10は、カスタム出力ディレクトリのアーティファクトをクリーニングできません

Xcodeにカスタム出力ディレクトリを使用する場合、Xcode 10へのアップグレード時に、Xcode Projectビルドランナーを使用したTeamCityビルドがエラーで失敗する場合があることに注意してください: " Could not delete <directory> because it was not created by the build system and it is not a subfolder of derived data."

This is caused by the following Xcode 10 known issue:
When performing xcodebuild clean on a project that uses a customized build location outside the derived data directory, and that has older build products produced prior to Xcode 10, Xcode might report an error indicating that it won't delete directories not created by the new build system. (40427159)
See Xcodeドキュメント(英語) for details.

この課題を解決するには、代わりにXcode 11を使用することをお勧めします。Xcode 10でこの課題を回避するには、出力ディレクトリを手動でクリーンアップするか、-UseNewBuildSystem=NO をコマンドラインパラメーターに渡して以前のビルドシステムを使用してみます。

TeamCityバージョンごとの課題

2020.1.1既知の課題

プロジェクトリストの展開ボタンがありません

In the TeamCity classic UI, the プロジェクト link in the header is missing the expand button.

To workaround this issue, please follow the instruction described here(英語).

2020.1 既知の問題

.NETランナーは廃止された外部.NET CLIサポートプラグインと互換性がありません

The reworked .NETビルドランナー is not compatible with the obsolete external .NET CLIサポート(英語) plugin (used in versions 2017.1 and earlier). If the obsolete plugin is installed on your server, you will get the Error creating bean with name "jetbrains.buildServer.dotnet.DotnetRunnerRunType" after updating to TeamCity 2020.1. To solve this issue, please uninstall the obsolete plugin from your server.

Note that all the existing .NET CLI Support build steps are automatically switched to the new .NET runner on updating to TeamCity 2019.2.3 or later. For more information, refer to our upgrade notes.

Jiraクラウド統合ビルド機能には特定のVCS URLが必要

The Jira Cloud API, used by the new Jira Cloud integration build feature, requires sending a server URL in a specific format. Because of that, the build feature does not support VCSs like Perforce, TFS, and SVN out of the box.

To address this issue, we have updated the responsible plugin, and you can find it attached to the related issue(英語) in our tracker. Please download the fixed plugin and install it as described here.
The bundled Jira Cloud plugin will be automatically updated with this fix in our next release.

The feature might also fail to resolve some Git paths that do not correspond to the format expected by the Jira Cloud API. In this case, you can either change the URL manually (for example, from git@<vcs_address>:<workspace_ID>/<repo_name>.git to ssh://git@<vcs_address>/<workspace_ID>/<repo_name>.git ) or download the fixed plugin as described above.

Jiraクラウド統合機能はレガシーJiraクラウドドメインをサポートしていません

Currently, the new Jira Cloud integration build feature supports only atlassian.net domains. We have added the support of the legacy jira.com domain in the fixed version of the responsible plugin. If your Jira Cloud server resides on the jira.com domain, you can download the plugin, attached to the related issue(英語), and install it as described here.
The bundled Jira Cloud plugin will be automatically updated with this fix in our next release.

Slackでの認証時の不正なリダイレクトURIエラー

To be able to sign in to Slack from TeamCity, you need to specify all the possible URIs of the TeamCity server as リダイレクトURL in the Slack app's settings.
If you use nginx to set up TeamCity behind a proxy server, you might still get the bad_redirect_uri error when trying to establish a connection with Slack. This error is caused by the mismatch between the nginx and Tomcat configuration.

To workaround this issue, download the fixed plugin, attached to the related issue(英語), and install it as described here. Alternatively, you can try updating the Tomcat settings.
The bundled Slack plugin will be automatically updated with this fix in our next release.

アップグレードされた2020.1 EAP1インストールの組み込み認証の問題

If you had installed the 2020.1 EAP1 build in terms of our Early Access Program, you might experience problems with signing in to TeamCity via the 組み込み認証 . This issue might occur after upgrading from any 2020.1 EAP version (EAP1 or any later version to which it was upgraded) to the release 2020.1 build.

To workaround this problem, please send the following query to the TeamCity database:

UPDATE users SET algorithm = 'BCRYPT' WHERE password like '$2a$07$%' and algorithm = 'MD5';

2019.2.3既知の課題

SSL接続の確立時のハンドシェイクの失敗

Some users might get the " 致命的なアラートを受信: handshake_failure " error when the TeamCity server attempts to establish an SSL connection. The problem is caused by the broken sunec.dll in JRE bundled with TeamCity 2019.2.3.

To check if this problem has affected your installation, open the <TeamCity_installation_directory>/jre/bin/sunec.dll file. If there is a JSON code in this file, your server is affected. To work around the problem, please follow the steps described in the related issue(英語).

外部リポジトリのNuGetフィード認証情報が.NETランナーで機能しない

.NETビルドランナーは現在、外部リポジトリでの認証にNuGetフィード資格情報を使用することをサポートしていません。

To work around this issue in TeamCity 2019.2.3, download the パッチが適用された.NETパッケージサポートプラグイン(英語) and install it as any other additional plugin. The bundled .NET Packages Support plugin will be automatically updated with the fix in our next release.

AWSリージョンus-east-1はS3アーティファクトストレージ設定で設定できません

S3アーティファクトストレージ設定で us-east-1 リージョンが選択されている場合、設定を保存すると、別の使用可能なリージョンに自動的にリセットされます。これは、AWSから us-east-1 に対して返された誤ったバケットの場所が原因です。

To work around this issue in TeamCity 2019.2.3, download the パッチが適用されたTeamCity S3ストレージプラグイン(英語) and install it as any other additional plugin. The bundled S3 Storage plugin will be automatically updated with the fix in our next release.

2019.2 既知の問題

.NETプロジェクトでのNuGetパッケージの復元に関する潜在的な課題

TeamCity might fail to restore NuGet packages if a build comprises at least one .NET CLI (dotnet) step and an MSビルド or Visual Studio (sln) build step (or both).

This issue is caused by the difference in paths to cache directories between these build runners.
The MSBuild and Visual Studio (sln) runners use the default path to the NuGet global cache while the .NET CLI (dotnet) runner redefines this path (for example, when run inside a Docker container).

推奨される回避策は、パッケージの復元に.NET CLI(dotnet)ランナーの代わりにNuGetインストーラビルドランナーを使用することです。

2019.1.4既知の課題

Amazon ECRで使用できないデフォルトの資格情報プロバイダーチェーンオプション

この課題はTeamCity 2019.1.5で修正されました。

Due to recent changes in our Docker Support plugin, the " デフォルトの資格情報プロバイダーチェーン(英語) " option becomes unavailable in the Amazon ECR connection settings.

If this option was previously enabled in some ECR connection and you make any changes to this connection, the state of this option will be automatically set to false . When any build will try to use this connection, it will fail to start with the " アクセスキーをnullにすることはできません " error.

To workaround this problem without upgrading to 2019.1.5, download the fixed Docker Support plugin from the related issue(英語) and upload it on the サーバー管理 | プラグインリスト page.

NuGetフィードに不足しているパッケージ

この課題はTeamCity 2019.1.5で修正されました。

特定のケースでは、ビルドで複数のNuGetパッケージを作成してNuGetフィードに公開することになっており、パッケージのインデックス付けが有効になっていると、一部のパッケージがフィードに公開されない場合があります。この問題は、NuGetパッケージインデクサの最近の変更が原因です。

To workaround this problem without upgrading to 2019.1.5, download the fixed NuGet Support plugin from the related issue(英語) and upload it on the サーバー管理 | プラグインリスト page.

最終更新日: 2020年8月03日