TeamCity 2020.2 ヘルプ

TeamCity データディレクトリ

TeamCity データディレクトリは、TeamCity サーバーが構成設定、ビルド結果、現在の操作ファイルを保存するために使用するファイルシステム上のディレクトリです。ディレクトリはすべての構成設定の主記憶域であり、TeamCity のインストールに不可欠なデータを保持しています。

ビルド履歴、ユーザーとそのデータ、その他のいくつかのデータは、データベースに保存されます。ディレクトリおよびデータベースに格納されているデータの説明については、バックアップに関する注意を参照してください。

このドキュメントや他の TeamCity 資料では、このディレクトリはしばしば .BuildServer と呼ばれています。別の名前が付いている場合は、.BuildServer を実際の名前に置き換えてください。

TeamCity データディレクトリの場所

現在使用されているデータディレクトリの場所は、実行中の TeamCity サーバーインスタンスの管理 | グローバル設定ページで確認できます。参照リンクをクリックすると管理 | グローバル設定 | データディレクトリの参照タブが開き、ユーザーはディレクトリ内の新しいファイルをアップロードしたり、既存のファイルを変更したりできます。

現在のデータディレクトリの場所は、logs/teamcity-server.log ファイルでも利用できます(サーバーの起動時に「 TeamCity データディレクトリ:」行を探します)。

TeamCity の初期バージョンのいずれかからアップグレードする場合は、TeamCity 7.1 より前のデータディレクトリは、以下で説明する方法とは異なる方法(英語)で指定される可能性があることに注意してください。

場所の設定

TeamCity データディレクトリの場所を設定するには、2 つの方法があります。

  • 最初のサーバー起動時に UI フォームでそれを選択する(TeamCity、.tar.gz または .exe ディストリビューションの場合のみ)。次に、指定されたデータディレクトリが <TeamCity home directory>/conf/teamcity-startup.properties ファイルに保存されます。

  • 手動TEAMCITY_DATA_PATH 環境変数を使用。変数は、システム全体にすることも、TeamCity サーバーを起動するユーザー用に定義することもできます。変数を設定 / 変更した後、変更を有効にするためにコンピューターを再起動する必要がある場合があります。

最初の起動時に、TeamCity が環境変数として構成されたデータディレクトリの場所を見つけると、関連する起動画面をスキップして、検出されたパスを使用します。

TEAMCITY_DATA_PATH 環境変数が設定されておらず、<TeamCity home directory>/conf/teamcity-startup.properties ファイルでも定義されていない場合、デフォルトの TeamCity データディレクトリの場所はユーザーのホームディレクトリになります(たとえば、Linux では $HOME/.BuildServer、Windows では %USERPROFILE%.BuildServer )。

データディレクトリの場所の選択に関する推奨事項

データディレクトリにはすべてのサーバーと構成されたプロジェクト設定が保存されるため、対応するアクセスレベルがないと、OS ユーザーの読み取りおよび書き込みに使用できないことが重要です。関連するセキュリティノートを参照してください。

デフォルトでは、system ディレクトリはビルドのすべてのアーティファクトとビルドログを履歴に保存するため、非常に大きくなる可能性があるため、TeamCity データディレクトリを非システムディスクに配置することをお勧めします。古いビルドの自動クリーニングを構成するには、クリーンアップページを参照してください。1 つのローカルディスクにすべてのアーティファクトを保存できない場合は、別のディスクを追加して、複数のアーティファクトパスを設定できます。

TeamCity は、TeamCity データディレクトリへの信頼性のある永続的な読み取り / 書き込みアクセスを想定しており、データディレクトリにアクセスできなくなると誤動作する可能性があることに注意してください。この誤動作は、ディレクトリが使用できない間、TeamCity の動作に影響を与える可能性があり、現在実行中のビルドのデータも破損する可能性があります。TeamCity は時々データディレクトリにアクセスできないことを許容できるはずですが、まれに、ディレクトリに保存されているデータが破損したり部分的に失われたりする場合があります。

特に TeamCity データディレクトリがネットワークストレージにある場合は、<TeamCity Data Directory>/system/caches をローカルディスクまたは別の専用ディスクに保存することをお勧めする: メインディレクトリから caches ディレクトリへのシンボリックリンクを作成するか、TeamCity 2020.1.1 以降、TEAMCITY_SERVER_OPTS 環境変数で指定できる teamcity.caches.path JVM システムプロパティを介してそのパスを再定義できます。

TEAMCITY_SERVER_OPTS=-Dteamcity.caches.path=<path to local caches directory>

caches ディレクトリには、VCS リポジトリのローカルクローンが格納されます。そのため、良好なパフォーマンスを提供することが重要です。ディレクトリの内容が失われた場合、再構築され、データは失われません。

TeamCity データディレクトリの構造

TeamCity データディレクトリの config サブディレクトリには TeamCity プロジェクトの設定が含まれ、system サブディレクトリにはビルドログ、アーティファクト、データベースファイル(デフォルトで内部データベース(HSQLDB)が使用されている場合)が含まれます。また、手動バックアップと復元に関する情報を検討して、どのデータがデータベースに保管されていて、どれがファイルシステムに保管されているかをよりよく理解することもできます。

  • BuildServer/config – a directory where projects, build configurations and general server settings are stored.

    • trash – backup copies of deleted projects, it is OK to delete them manually. For details on restoring the projects check 使い方

    • notifications – notification templates and notification configuration settings, including syndication feeds template.

    • logginginternal server logging configuration files, new files can be added to the directory manually.

    • projects – a directory which contains all project-related settings. Each project has its own directory. Project hierarchy is not used and all the projects have a corresponding directory residing directly under "projects".
      • <projectID> – a directory containing all the settings of a project with the <projectID> ID (including build configuration settings and excluding subproject settings). New directories can be created provided they have mandatory nested files. The Root directory contains settings of the root project. Whenever *.xml.N files occur under the directory, they are backup copies of corresponding files created when a project configuration is changed via the web UI. These backup copies are not used by TeamCity.
        • buildNumbers – a directory which contains <buildConfigurationID>.buildNumbers.properties files which store the current build number counter for the corresponding build configuration.

        • buildTypes – a directory with <buildConfiguration or template ID>.xml files with corresponding build configuration or template settings.

        • pluginData – a directory to store optional and plugin-related project-level settings. Bundled plugins settings and auxiliary project settings like custom project tabs are stored in the plugin-settings.xml file in the directory. Credentials stored outside of VCS per Versioned settings are stored in the secure/credentials.json file.

        • vcsRoots – a directory which contains project's VCS roots settings in the files <VcsRootID>.xml .

        • project-config.xml – the project configuration file containing the project settings, such as parameters and クリーンアップ規則

    • main-config.xml – server-wide configuration settings.

    • database.properties – database connection settings, see more at 外部データベースの設定

    • license.keys – a file which stores the license keys entered into TeamCity.

    • change-viewers.properties外部変更ビューアー configuration properties, if available.

    • internal.properties – file for specifying various internal TeamCity properties. It is not present by default and needs to be created if necessary.

    • auth-config.xml – a file storing server-wide authentication-related settings.

    • ldap-config.propertiesLDAP 認証 configuration properties.

    • ntlm-config.propertiesWindows ドメイン認証 configuration properties.

    • issue-tracker.xml – issue tracker integration settings.

    • cloud-profiles.xml – Cloud (for example, Amazon EC2) integration settings.

    • backup-config.xml – web UI backup configuration settings.

    • roles-config.xml – roles-permissions assignment file.

    • database.*.properties – default template connection settings files for different external databases.

    • *.dtd – DTD files for the XML configuration files.

    • *.dist – default template configuration files for the corresponding files without .dist . See below.

  • .BuildServer/plugins – a directory where TeamCity plugins can be stored to be loaded automatically on the TeamCity start. New plugins can be added to the directory. Existing ones can be removed while the server is not running. The structure of a plugin is described in プラグインのパッケージング(英語)

  • .BuildServer/system – a directory where build results data is stored. The content of the directory is generated by TeamCity and is not meant for manual editing.

    • artifacts – the default directory where the builds' artifacts, logs and other data are stored: アーティファクトストレージの形式は <project ID>/<build configuration name>/<internal_build_id> です(内部ビルド ID の詳細を参照してください)。必要に応じて、各ビルドのディレクトリ内のファイルを手動で追加 / 削除できます。これは、対応するビルドのアーティファクトに反映されます。
      • .teamcity サブディレクトリには、ビルドの非表示のアーティファクトとビルドログが格納されます(以下を参照)。ファイルは必要に応じて手動で削除できますが、ビルドによってファイルに裏付けられた対応する機能が失われるため、お勧めしません(ビルドログ、スナップショットの依存関係としてのビルドの再利用、カバレッジレポートなど、完成したビルドパラメーターの表示 / 使用)、等々)
        • logs サブディレクトリは、ビルドログを内部形式で保存します。ビルドログには、ビルド出力、コンパイルエラー、テスト出力、テスト失敗の詳細が保存されます。ファイルは必要に応じて手動で削除できますが、対応するビルドではビルドログと失敗の詳細(およびテストの失敗の詳細)が失われます。

    • messages – a directory where build logs used to be stored before TeamCity 9.0. After automatic build logs migration to the new place under artifacts, the directory stores the files which could not be moved (see server log on the server start about details).

    • changes – a directory where the remote run changes are stored in internal format. Name of the files inside the directory contains internal personal change id. The files can be deleted manually, if necessary, but corresponding personal builds will lose personal changes in UI and when affected queued builds try to start, they fail or run without personal patch.

    • pluginData – a directory storing various data concerning builds, current system state, and so on: このディレクトリを削除または変更することはお勧めしません: (たとえば、TeamCity 2018.2 の前は、ビルドトリガーの状態がこのディレクトリに保存されていました)。このディレクトリの内容はデータベースに保存されているデータに対応しているため、データベースを復元するときは、データベースとの整合性を保つために、このディレクトリを同じ状態に復元する必要があります。

    • audit – directory holding history of the build configuration changes and used to display diff of the changes. Also stores related data in the database.

    • repositoryStates – before TeamCity 2018.2, it was used to store the current state of the VCS roots that were moved to the database in 2018.2. If dropped, some changes might not be detected by TeamCity (between the state last queried by TeamCity and the current state after first server start without this data).

    • caches – a directory with internal caches (of the VCS repository contents, search index, other). It can be manually deleted to clear caches: they will be restored automatically as needed. It is safer to delete the directory while server is not running.
      • .unpacked – directory that is created automatically to store unpacked server-side plugins. Should not be modified while the server is running. Can be safely deleted if the server is not running.

    • buildserver.* – a set of files pertaining to the embedded HSQLDB.

  • .BuildServer/backup – default directory to store backup archives created via web UI. The files in this directory are not used by TeamCity and can be safely removed if they were already copied for safekeeping.

  • .BuildServer/lib/jdbc – directory that TeamCity uses to search for database drivers. Create the directory if necessary. TeamCity does not manage the files in the directory, it only scans it for .jar files that store the necessary driver.

設定ファイルの直接変更

config ディレクトリのファイルは手動で編集することができます(特に明記しない限り)。変更はサーバーの再起動なしで考慮されます。TeamCity はこれらのファイルの変更を監視し、変更または新しいファイルが検出されると自動的に再読み込みします。これらのファイルの物理的または論理的な構造を壊すのは簡単なので、細心の注意を払って編集することを忘れないでください。変更を加える前に、必ずデータをバックアップしてください。

ファイルのフォーマットはより新しい TeamCity バージョンと変わることができるためファイル更新手順はアップグレードの後で調整を必要とするかもしれないことに注意してください。

REST API は最も一般的な設定編集のための手段を持ち、サーバーアップグレード後に機能するという点でより安定しています。

.dist テンプレート設定ファイル

手動編集用の設定ファイルの多くは、次の規則を使用しています。

  • fileName という名前の)ファイルと一緒に、ファイル fileName.dist が作成されます。 .dist ファイルは、デフォルトのサーバー設定を保存するためのものであり、fileName 構成のサンプルとして使用できます。 .dist ファイルは、サーバーを起動するたびに上書きされるため、手動で編集しないでください。また、fileName ファイルがユーザーによって変更されたかどうか、または後者を更新できるかどうかを決定するために、サーバーのアップグレード中に .dist ファイルが使用されます。

XML 構造と参照

構成を手動で変更する場合は、ID によって相互リンクされたエントリがあることに注意してください。このようなエントリの例は、ビルド構成 -> VCS ルートリンクおよびプロジェクト -> 親プロジェクトリンクです。同じタイプのすべてのエントリは、サーバー全体で一意の ID を持っている必要があります。新しいエントリは、ID が一意である場合にのみ追加できます。

TeamCity サーバー間でのプロジェクトの移動に関する関連セクションも参照してください。

関連ページ:

外部データベースの設定

TeamCity はビルド履歴、ユーザー、ビルド結果、いくつかのランタイムデータを SQL データベースに保存します。手動バックアップと復元ページのどこに格納されているかの説明も参照してください。本番用に推奨されていない内部データベースを使用して TeamCity を評価した場合は、外部データベース...

クリーンアップ

TeamCity のクリーンアップ機能により、古いビルドデータや不要なビルドデータを自動的に削除できます。サーバーのクリーンアップ構成は管理 | サーバー管理 | クリーンアップ設定で使用可能です。クリーンアップスケジュールの設定が可能で、一般的なクリーンアップ情報が表示されます。特定のプロジェクト...

外部変更ビューアー

TeamCity は、JetBrains Upsource、Atlassian Fisheye などの外部変更ビューアーとの統合をサポートしています。TeamCity 2017.2 以降、一部のビューアーはそのまま使用できます。GitHub、VSTS、または Bitbucket へのコミットが自動的...

パーソナルビルド

パーソナルビルドは、一般的なビルドシーケンスのビルドアウトであり、通常はバージョン管理にまだコミットされていない変更を使用します。パーソナルビルドは通常、サポートされている IDEの 1 つからリモート実行プロシージャを介して開始されます。以下で説明するように、変更を含むパッチをサーバーに直接アップ...