TeamCity 2020.1 ヘルプ

既知の問題

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

TeamCity の特定のバージョンに固有の課題を確認するには、それぞれのセクションにアクセスしてください。

Incompatibility with JDK 8 update 242+

TeamCity versions up to 2019.2.1 running under JDK 8u242+ can report java.lang.NoClassDefFoundError: Could not initialize class XXX errors, for example, on Git operations or Windows domain authentication operations.

Until TeamCity 2019.2.2 is released, it is recommended to use Java 8u232 version for TeamCity server.

Agent running as Windows Service Limitations

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.

Security-related issues

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. Change SYSTEM for a usual user account with necessary permissions granted.

  2. Restart the service.

Windows service limitations

As a Windows service, the TeamCity agent and the build processes are not able to access network shares and mapped drives.

To overcome these restrictions, run TeamCity agent via console.

Issues with automated GUI and browser testing

These problems include errors running tests headless, issues with the interaction of the TeamCity agent with the Windows desktop, and so on.

To resolve / avoid these:

  1. Run TeamCity agent via console.

  2. Configure the build agent machine not to launch a screensaver locking the desktop.

  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).

For graphical tests the build agent cannot be started as a service and it is recommended to configure the build agent launch with a 1 minute delay after the user auto-logon, e.g. using the bin\agent.bat start command in the task scheduler and configuring the delay there.

Running automated GUI tests and using RDP

RDP uses its own video driver overriding the one from the machine's video card for the session. Redirecting the session to console will unload the Windows graphical drivers. This can be done by adding the following step to your build configuration prior to your tests (the example below is for PowerShell, but other languages (DOS, Python) can be used too):

$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".

Issues with .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.

Early start of the service before other resources are initialized

To handle this, consider using the Automatic (Delayed Start) option of the service settings or configure service dependencies(英語).

For more investigation steps, see the Common Problems page.

java.lang.OutOfMemoryError: unable to create new native thread error

If your TeamCity server is running on SUSE ® Linux Enterprise (or using systemd Daemon), the java.lang.OutOfMemoryError: unable to create new native thread error 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.

Increasing the limit (e.g. to 4096) on the TeamCity server should solve the issue.

See also this external posting(英語).

Clearing Browser Ca с hes

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(英語).

Logging with Log4j in Your Tests

If you use Log4j logging in your tests, in some cases you may miss the Log4j output from your logs. In such cases do the following:

  • Use Log4j 1.2.12

  • For Log4j 1.2.13+, add the " Follow=true " parameter for the console appender used in Log4j configuration:

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

Agent Service Can Exit on User Logout under Windows x64

The used version of Java Service Wrapper(英語) does not fully support Windows 64 and this causes agent launcher process to be killed on user logout. The agent itself will be function until the next restart (server upgrade or agent properties change).

Failed Build Can be Reported as a Successful One With 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

with the following one:

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

Conflicting Software

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 antivirus can also slow down Ant/IntelliJ IDEA project builds a great deal (slowing down TCP connections to localhost on agent).

If you run antivirus on the TeamCity server or agent machines and get disk access errors or experience degraded performance, disable or better completely uninstall the antivirus software before investigating the issue and reporting the issue to JetBrains.

It is recommended to exclude entire TeamCity server home and TeamCity Data Directory from the background checks and perform periodical checks there in the well-known maintenance window so that those do not affect server performance much. On TeamCity agent, it is recommended to exclude TeamCity agent home from the background checks.

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.

Do not install software with background indexing like WinCVS, TortoiseCVS, TortoiseSVN, and other Tortoise* products. This applies to server and also to agents if you use agent-side checkout.

Skype software is known to:

  • use port 80 on the system so you might not be able to utilize a TeamCity server on the default port 80.

  • corrupt layout of pages displayed in Internet Explorer. Internet Explorer Skype plugin is to blame. (TW-13052(英語)).

Subversion issues

svn: E175002: Received fatal alert: bad_record_mac

Add a system property -Dsvnkit.http.sslProtocols=SSLv3,TLS on the build server (see Configuring TeamCity Server Startup Properties).
If you use checkout on agent, add this property on build agent as well.

Subversion-related JVM Crashes

If JVM crashes while executing SVN-related code (e.g. under org.tmatesoft.svn package), you can try to disable it using one of the options:

  • Passing -Dsvnkit.useJNA=false JVM option to the crashing process (server or agent)

  • 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 Performance

Due to an issue in NUnit 2.4.6, its performance may be slower than NUnit 2.4.1. For additional information, refer to the corresponding issue in our issue tracker: TW-4709(英語)

StarTeam Performance

Using StarTeam SDK 9.0 instead of StarTeam SDK 9.3 on the TeamCity server can significantly improve VCS performance when there is a slow connection between TeamCity and StarTeam servers.

Perforce 2009.2 Performance on Windows

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.

Wrong times for build scheduled triggering (Timezone issues)

Make sure you use the latest update for Java 8 installation available for your platform (e.g. OpenJDK 8 by Amazon Corretto(英語)).

Upgrading IntelliJ IDEA May Affect Active Pre-Tested Commits

Before you upgrade to IntelliJ IDEA X (or other IntelliJ X platform products), make sure you do not have active pre-tested commits, otherwise they will not be able to be committed after upgrade. This is only relevant if you use directory-based IDEA project (project files are stored under .idea directory).

Other Java Applications Running on the Same Server

If other web applications are available via the same hostname, a session cookie conflict can occur. This usually is visible via random user logouts or losing session-level data. (e.g. TW-12654(英語)). To resolve this, you can use different host names when accessing the applications.

The Server Does Not Start Claiming the Database is in Use

Only a single TeamCity server can work with one database, which is checked on the TeamCity server start.

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

  • An attempt to start more than one TeamCity server connected to the same database

  • A second TeamCity instance detected

  • The internal HSQL database is being used by another application

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.

In TeamCity 8.0 and earlier, if all the settings are correct, the error can occur when the TeamCity server or the database server has been shut down incorrectly. The resolution depends on the database type:

  • MySQL: restart the MySQL server and then start TeamCity again.

  • PostgreSQL, Oracle, MS SQL: kill the connections from the incorrectly shut down TeamCity, and then start TeamCity again.

  • Internal database (HSQL): remove the buildserver.lck file from the <TeamCity Home>\system directory, and then start TeamCity again.

Slow download from TeamCity server

If you experience slow speed when downloading artifacts from TeamCity, try checking the speed on the server machine, downloading from localhost. If the speed is OK for the localhost, the issue can be in the network configuration or OS/hardware settings when combined with TeamCity (Tomcat) settings.

Make sure <TeamCity Home>\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" />

change it to:

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

and restart TeamCity server.

If this does not help with the download speed, to investigate the case, you might need to find an administrator with appropriate network-related issues investigation skills to look into the case.

Failure to publish artifacts to server behind IIS reverse proxy

This problem is only relevant to configurations that involve an IIS reverse proxy between the build server and agents. Sometimes a build agent can be found in infinite loop trying to publish build artifacts to the server. The build log looks like this:

[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/**

meanwhile teamcity-agent.log is filled with 404 responses from IIS:

[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;}

The most common cause for this is maxAllowedContentLength setting (in IIS) is either

  • set to too small value, or

  • left unconfigured and so defaults to 30000000 bytes (<30 Mb)

So any artifact larger than maxAllowedContentLength is discarded by IISCheck the settings value and try to rerun your build

Prerelease packages are not visible in the TeamCity NuGet feed

Problem: Prerelease packages are not visible in the TeamCity NuGet feed.

Cause: NuGet clients prior to version 3 fail to list prerelease packages if the package version violates the required format(英語).

Solution: Delete build artifacts whose versions violate the required format(英語).

Packages indexing is slow in TeamCity NuGet feed

Problem: After TeamCity server host machine move or upgrade to the TeamCity 2017.1 build metadata can be reset.

Cause: The TeamCity NuGet feed relies on build metadata, and packages re-indexing can take a lot of time depending on the number of packages and the idle time of the TeamCity server.

Solution: To speed up build metadata re-indexing, specify the following internal properties:

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

To check the metadata indexing progress, look for lines similar to the ones below in the teamcity-server.log file:

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

After re-indexing is complete, remove these internal properties.

SSL problems when connecting to HTTPS from TeamCity (handshake alert: unrecognized_name)

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(英語).

SSL problems connecting MS SQL Server and TeamCity

Since MS SQL Server always establishes an SSL connection between the jdbc client (the TeamCity application) and the server, connection problems may occur (SQL exception: Connection reset).

Affected MS SQL versions

Any version prior to the ones listed below:

  • SQL Server 2012 Production version and later

  • SQL Server 2008 Service Pack 3 Cumulative Update 4

  • SQL Server 2008R2 Service Pack 1 Cumulative Update 6

  • SQL Server 2008R2 Service Pack 2

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

Solution: Microsoft SQL Server upgrade is recommended.

Workarounds: If Microsoft SQL Server upgrade is not possible for some reason, TeamCity can be set up to use older Microsoft SQL Server versions with the database connection still SSL- or TLS-encrypted.

  • 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.

  • Fall back to a stream cipher (which is not susceptible to BEAST) such as RC4_128. This will render the connection vulnerable to CVE-2015-2808(英語)

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

Distorted Configuration Window During Agent Reinstallation

When installing a TeamCity agent via a Windows agent installer on top of the already installed agent with a different version of Java, the" Configure Build Agent Properties "installation window might appear distorted.

This issue has been fixed in 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 Agent Home Directory, clear all the" Remove... "checkboxes to keep the agent logs and configuration, and click Uninstall. After the successful uninstallation, you can proceed with installing the new agent version via the agent installer.

Windows Docker Containers

Problems common to TeamCity Docker container images.

  • Since Windows 10 version 1803 with KB4340917(英語) it's possible to use port mapping from containers to localhost. For previous Windows versions it works for the non-localhost IP address associated with this machine and you can access a running application via the machine's hostname or determine the IP address via the ipconfig command. Note that the netstat -an command may not show that the port is open on any IP address, while in fact it can work. This is also a known problem of Docker on Windows.

  • On Windows 10, the memory allocated per container is 1GB by default. To increase this value, use the following memory options:

    docker run ... -m 2GB -e TEAMCITY_SERVER_MEM_OPTS="-Xmx2g -XX:ReservedCodeCacheSize=350m"
  • On Windows 10 containers work via Hyper-V and may experience problems with network and other subsystems. To diagnose these problems, execute the following PowerShell script:

    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 "Authenticated Users" the Full Control over the directories used as volumes. See the related issue(英語).

  • 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: "Invalid path '/ContainerMappedDirectories': No such file or directory". 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 clean-up scripts(英語).

More details on troubleshooting Docker for Windows are available in the Docker(英語) and Microsoft(英語) documentation.

Information about installed Docker server OS on Windows missing on Agent

On Windows 10, the Docker server depends on Hyper-V service and its start may take a significant amount of time. To resolve the issue, configure the TCBuildAgent Windows service to depend on the Docker for Windows Service, com.docker.service by default.

Linux Docker Containers under Windows

Since TeamCity 2017.2, the Docker Wrapper works on Windows when Windows-based containers are started.

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 Windows エージェントの要件は含まれていません。

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

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

Windows Docker コンテナーを使用する場合、コンテナー(英語)のシステム時刻がホストマシンの時刻と同期しなくなると、Windows コンテナーの時刻が正しく(英語)なくなるという課題があります。応答時間が重要な統合(OAuth トークンなど)で課題が発生する可能性があります。

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

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

Docker がプロセスアイソレーションで Windows コンテナーを起動するとき、Docker ボリュームのあるディレクトリへの書き込みアクセス権がない Windows ユーザーアカウントを使用します。この場合、「パスへのアクセスが拒否されました」または「アクセスは拒否されました」エラーが原因で、ビルドエージェントが起動しないことがあります。

この課題を解決するには、%\PROGRAMDATA%\docker\volumes ディレクトリの「Authenticated Users」グループに「フルコントロール」権限を付与します。

dotCover の既知の課題

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

Nano Server OS を搭載したエージェントで dotCover を実行しようとすると、ビルドは終了エラー「コード -1073741515 でプロセスが終了しました」で失敗します。Nano Server の代わりに、Windows Server の代替最小インストールオプションであるサーバーコア(英語)の使用を検討してください。

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

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

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

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

.testsettings ファイルを使用する場合、TeamCity はログに警告メッセージを表示します。この課題を回避するには、代わりに .runsettings (英語) ファイルを使用することをお勧めします。何らかの理由で .testsettings を引き続き使用する必要がある場合は、ここで説明するように、TeamCity エージェントに dotCover バージョン 2019.1.x 以前をインストールします。

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

Xcode にカスタム出力ディレクトリを使用する場合、Xcode 10 へのアップグレード時に、Xcode Project ビルドランナーを使用した TeamCity ビルドがエラーで失敗する場合があることに注意してください :" < ディレクトリ > は、ビルドシステムによって作成されたものではなく、派生データのサブフォルダーではないため、削除できませんでした。

これは、次の Xcode 10 の既知の課題が原因です。
派生データディレクトリ外のカスタマイズされたビルド場所を使用し、Xcode 10 より前の古いビルド製品が含まれるプロジェクトで xcodebuild clean を実行すると、Xcode は、新しいビルドシステムで作成されていないディレクトリを削除しないことを示すエラーを報告する場合があります。(40427159)
詳細については、Xcode ドキュメント(英語)を参照してください。

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

クロスサーバープロジェクトのポップアップメニューが最新のブラウザーで機能しない場合がある

SameSite Cookie(英語) サポートの最近の更新により、一部の最新の Web ブラウザーではプロジェクトポップアップメニューにクロスサーバープロジェクトが表示されない場合があります(Chrome プラットフォームの詳細(英語)を参照)。

クロスサーバープロジェクトメニューにアクセスできない場合は、ブラウザの設定を変更して、この課題を一時的に回避することができます。

  • Google Chrome で chrome://flags ページを開き、 "を無効にします。デフォルトの Cookie による SameSite" オプション。

  • Mozilla Firefox で about:config ページを開き、network.cookie.sameSite.laxByDefault オプションを無効にします。

  • Safari で、環境設定 | プライバシーに移動して " を無効にします。クロスサイトトラッキングを防止する "オプション。

この課題は、TeamCity 2020.1.5 アップデートで解決されます。詳細については、関連する課題(英語)を参照してください。

.NET ランナーの既知の課題

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

再加工された .NET ビルドランナーは、廃止された外部プラグイン .NET CLI サポート(英語)(バージョン 2017.1 以前で使用)と互換性がありません。廃止されたプラグインがサーバーにインストールされている場合は、TeamCity 2020.1 に更新した後に " jetbrains.buildServer.dotnet.DotnetRunnerRunType" という名前の bean の作成中にエラーが発生しましたを取得します。この課題を解決するには、廃止されたプラグインをサーバーからアンインストールしてください。

TeamCity 2019.2.3 以降に更新すると、既存のすべての .NET CLI サポートビルドステップが新しい .NET ランナーに自動的に切り替えられることに注意してください。詳細については、アップグレードノートを参照してください。

初期の Visual Studio2017build を使用している場合、ロガーのインスタンスを作成できません

まれに、Visual Studio2017 の初期ビルドがビルドエージェントにインストールされている場合、「ロガーのインスタンスを作成できません」というメッセージが表示されることがあります。.NET ビルドステップの実行時にエラーが発生しました。これは、使用されているフレームワークバージョンとのロガーの非互換性が原因である可能性があります。

この問題を回避するには、Visual Studio2017 を最新のビルドにアップグレードするか、またはそれ以降のバージョンの .NET フレームワークをインストールします。

TeamCity バージョンごとの課題

2020.1.3 既知の課題

スナップショットの依存関係がないチェーンビルドの再実行ビルドダイアログをぶら下げ

アーティファクト依存関係はあるが、別のビルドでスナップショット依存関係がないビルドを再実行しようとすると、ビルドを再実行ダイアログは読み込まれません。

この課題は TeamCity 2020.1.4 で修正される予定です。バージョン 2020.1.3 でこの課題を回避するには、この指示(英語)に従ってください。

2020.1.1 既知の課題

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

TeamCity クラシック UI では、ヘッダーのプロジェクトリンクに展開ボタンがありません。

この課題を回避するには、こちらに記載されている手順に従ってください。

2020.1 既知の問題

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

新しい Jira クラウド統合ビルド機能で使用される Jira クラウド API では、サーバー URL を特定の形式で送信する必要があります。そのため、ビルド機能は、Perforce、TFS、SVN などの VCS をそのままではサポートしていません。

この課題に対処するために、責任のあるプラグインを更新しました。トラッカーで関連する課題(英語)に添付されているプラグインを見つけることができます。固定プラグインをダウンロードして、ここで説明するようにインストールしてください。
バンドルされている Jira Cloud プラグインは、次のリリースでこの修正により自動的に更新されます。

この機能は、Jira クラウド API が予期する形式に対応しない一部の Git パスの解決に失敗する場合もあります。この場合、URL を手動で(たとえば、git@<vcs_address>:<workspace_ID>/<repo_name>.git から ssh://git@<vcs_address>/<workspace_ID>/<repo_name>.git に)変更するか、上記のように固定プラグインをダウンロードできます。

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

現在、新しい Jira クラウド統合ビルド機能は atlassian.net ドメインのみをサポートしています。責任のあるプラグインの修正バージョンにレガシー jira.com ドメインのサポートを追加しました。Jira クラウドサーバーが jira.com ドメインにある場合は、関連する課題(英語)に添付されているプラグインをダウンロードし、ここで説明するようにインストールできます。
バンドルされている Jira Cloud プラグインは、次のリリースでこの修正により自動的に更新されます。

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

TeamCity から Slack にサインインできるようにするには、TeamCity サーバーのすべての可能な URI を Slack アプリ設定でリダイレクト URL として指定する必要があります。
nginx を使用してプロキシサーバーの背後で TeamCity を設定した場合でも、Slack との接続を確立しようとすると、bad_redirect_uri エラーが発生する可能性があります。このエラーは、nginx と Tomcat の構成の不一致が原因で発生します。

この課題を回避するには、関連する課題(英語)に添付されている修正済みプラグインをダウンロードし、こちらの説明に従ってインストールします。または、Tomcat 設定の更新を試すこともできます。
バンドルされている Slack プラグインは、次のリリースでこの修正により自動的に更新されます。

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

早期アクセスプログラムの観点から 2020.1 EAP1 ビルドをインストールした場合、組み込み認証を介した TeamCity へのサインインで課題が発生する可能性があります。この課題は、2020.1 EAP バージョン(EAP1 またはそれ以降にアップグレードされたバージョン)からリリース 2020.1 ビルドにアップグレードした後に発生する可能性があります。

この問題を回避するには、次のクエリを TeamCity データベースに送信してください。

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

2019.2.3 既知の課題

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

TeamCity サーバーが SSL 接続を確立しようとすると、「致命的なアラートを受信 : handshake_failure」エラーが発生する場合があります。この問題は、TeamCity 2019.2.3 にバンドルされている JRE の壊れた sunec.dll が原因で発生します。

この課題がインストールに影響したかどうかを確認するには、<TeamCity_installation_directory>/jre/bin/sunec.dll ファイルを開きます。このファイルに JSON コードがある場合、サーバーが影響を受けます。この課題を回避するには、関連する課題(英語)で説明されている手順に従ってください。

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

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

TeamCity 2019.2.3 でこの課題を回避するには、パッチが適用された .NET パッケージサポートプラグイン(英語)をダウンロードして、他の追加プラグインとしてインストールします。バンドルされている .NET パッケージサポートプラグインは、次のリリースで修正により自動的に更新されます。

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

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

TeamCity 2019.2.3 でこの課題を回避するには、パッチが適用された TeamCity S3 ストレージプラグイン(英語)をダウンロードして、他の追加プラグインとしてインストールします。バンドルされている S3 Storage プラグインは、次のリリースで修正により自動的に更新されます。

2019.2 既知の問題

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

ビルドに少なくとも 1 つの .NET CLI(dotnet)ステップと MS ビルドまたは Visual Studio (sln) ビルドステップ(またはその両方)が含まれている場合、TeamCity は NuGet パッケージの復元に失敗する可能性があります。

この課題は、これらのビルドランナー間のキャッシュディレクトリへのパスの違いが原因で発生します。
MSBuild および Visual Studio(sln)ランナーは NuGet グローバルキャッシュへのデフォルトパスを使用しますが、.NET CLI(dotnet)ランナーはこのパスを再定義します(たとえば、Docker コンテナー内で実行する場合)。

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

2019.1.4 既知の課題

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

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

Docker サポートプラグインの最近の変更により、Amazon ECR 接続設定で「デフォルトの資格情報プロバイダーチェーン(英語)」オプションが使用できなくなります。

一部の ECR 接続でこのオプションが以前に有効になっており、この接続に変更を加えた場合、このオプションの状態は自動的に false に設定されます。ビルドがこの接続を使用しようとすると、「アクセスキーを null にすることはできません」エラーで開始できません。

2019.1.5 にアップグレードせずにこの課題を回避するには、関連する課題(英語)から修正済みの Docker サポートプラグインをダウンロードし、サーバー管理 | プラグインリストページにアップロードします。

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

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

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

2019.1.5 にアップグレードせずにこの課題を回避するには、関連する課題(英語)から修正済みの NuGet サポートプラグインをダウンロードし、サーバー管理 | プラグインリストページにアップロードします。

最終更新日 :