アーティファクトの依存関係
このページでは、TeamCity アーティファクトの依存関係の構成について詳しく説明します。
ビルド設定 | 依存関係 | アーティファクトの依存関係セクションでは、これらの依存関係を構成できます。アーティファクトの依存関係リストの最後の列にある対応するオプションを使用して、構成された依存関係を一時的または永続的に無効にすることができます。
Web UI を使用したアーティファクトの依存関係の設定
ビルド構成にアーティファクト依存関係を追加するには、以下のようにします。
ビルド構成を編集するときは、依存関係ページを開きます。
新しいアーティファクト依存関係を追加するをクリックして、次の設定を指定します。
オプション | 説明 |
---|---|
依存先 | 現在のビルド構成に依存するビルド構成を指定します。依存関係は、同じビルド構成の前のビルドに対して構成できます。 |
からアーティファクトを入手する | アーティファクトを取得するビルドの型を指定します。
|
ビルド番号 | このフィールドは、からアーティファクトを入手するリストで特定のビルド番号を持つビルドを選択した場合に表示されます。 |
ビルドタグ | このフィールドは、からアーティファクトを入手するリストで指定されたタグを持つ最後に完了したビルドを選択した場合に表示されます。 |
ブランチフィルターの作成 | このフィールドは、依存関係に VCS ルート設定で指定されたブランチがある場合に表示されます。ブランチフィルターを設定して、ソースビルドを一致するブランチ内のもののみに制限できます。指定しない場合、デフォルトのブランチが使用されます。 |
アーティファクトルール | このセクションを参照してください。 |
アーティファクトをダウンロードする前に宛先パスを消去する | アーティファクトをコピーする前に、このオプションをオンにして宛先ディレクトリのコンテンツを削除します。これはすべての包括的ルールに適用されます。 |
いつでもカスタムアーティファクトの依存関係を使用してビルドを起動できます。
アーティファクトルール
ここでは、ダウンロードするソースビルドのアーティファクトと、依存ビルドが開始される前にダウンロードされるエージェント上の場所を指定します。
改行で区切られた一連の規則。各規則は、次の構文を持つ必要があります。
各ルールは、「ソース」ビルドからダウンロードされるファイルを指定します。SourcePath は、「ソース」ビルドのアーティファクトのディレクトリに対する相対パスである必要があります。パスは特定のファイルやディレクトリを識別することも、ワイルドカードを使用して複数のファイルと一致させることもできます。Ant のようなワイルドカードがサポートされています。
ダウンロードされたアーティファクトは、最初の *
または ?
で始まる「ソース」ディレクトリ構造を保持します。
DestinationPath は、ダウンロードされたアーティファクトが配置されるエージェント上の宛先ディレクトリを指定します。パスが相対パスである場合 (これが推奨されます)、ビルドチェックアウトディレクトリに対して解決されます。必要に応じて、アーティファクトをダウンロードする前に宛先ディレクトリをクリーンアップできます。宛先パスが空の場合、アーティファクトはチェックアウトルートに直接ダウンロードされます。
基本的な例:
a/b/**=>lib
を使用して、ソースビルドのa/b
ディレクトリからlib
ディレクトリにすべてのファイルをダウンロードします。ソースビルドアーティファクトにa/b/c/file.txt
ファイルがある場合は、lib/c/file.txt
ファイルにダウンロードされます。同時に、アーティファクト依存関係
**/*.txt=>lib
はディレクトリ構造を保存します。ソースビルドアーティファクトからのa/b/c/file.txt
ファイルはlib/a/b/c/file.txt
にダウンロードされます。
ArchivePath は、ダウンロードした圧縮アーティファクトを抽出するために使用されます。zip
、7zip
、jar
、tar
、tar.gz
がサポートされています。
ArchivePath は SourcePath の一般的なルールに従います: ant のようなワイルドカードが許可されており、アーカイブ内で一致したファイルは、最初のワイルドカード一致に対応するディレクトリに配置されます(宛先パスを基準に)
たとえば: release.zip!*.dll
コマンドは、release.zip
アーティファクトのルートにあるすべての .dll ファイルを抽出します。
アーカイブ処理例
release-*.zip!*.dll=>dlls
は、release-*.zip
パターンに一致するすべてのアーカイブから*.dll
をdlls
ディレクトリに抽出します。a.zip!**=>destination
はパス情報を保存しているアーカイブ全体を解凍します。a.zip!a/b/c/**/*.dll=>dlls
は、a/b/c
プレフィックスなしで、a/b/c
およびそのサブディレクトリからすべての.dll
ファイルをdlls
ディレクトリに抽出します。
+:
および -:
を使用して、ダウンロードまたは解凍から特定のファイルを含めたり除外したりできます。+:
プレフィックスは省略できるため、ルールはデフォルトで包括的であり、少なくとも 1 つの包括的ルールが必要です。ルールの順序は重要ではありません。アーティファクトごとに、最も具体的なルール(最初のワイルドカードシンボルの前にプレフィックスが最も長いルール)が適用されます。ファイルを除外する場合、DestinationPath は無視されます。ファイルはまったくダウンロードされません。ファイルは、アーカイブの解凍から除外することもできます。アーカイブコンテンツに適用されるルールのセットは、アーカイブ自体と一致するルールのセットによって決定されます。
独占パターンの例:
**/*.txt=>texts
-:bad/exclude.txt
は、bad
ディレクトリのexclude.txt
を除く、すべてのディレクトリからすべての*.txt
ファイルをダウンロードします。+:release-*.zip!**/*.dll=>dlls
-:release-0.0.1.zip!Bad.dll
すべての*.dll
ファイルをrelease-*.zip
ファイルから*.dll
のディレクトリにダウンロードして解凍します。release-0.0.1.zip
のBad.dll
ファイルはスキップされます**/*.*=>target
-:excl/**/*.*
+:excl/must_have.txt=>target
すべてのアーティファクトをtarget
ディレクトリにダウンロードします。excl
ディレクトリからは何もダウンロードされませんが、must_have.txt
というファイルがダウンロードされます
.teamcity
ディレクトリに配置されたアーティファクトは、非表示とみなされます。これらのアーティファクトは、デフォルトではワイルドカードによって無視されます。
何らかの目的で .teamcity
ディレクトリのファイルを含める場合は、必ず .teamcity
で始まるアーティファクトパスを明示的に追加してください。
非表示のアーティファクトにアクセスする例
.teamcity/properties/*.properties
.teamcity/*.*
デフォルトでは、アーティファクトの依存関係をエージェントの作業ディレクトリにダウンロードすることは許可されていますが、エージェントのホームディレクトリは禁止されています。デフォルトをオーバーライドするには、 buildAgent.properties
でコンマ区切りのパス ( teamcity.artifactDependenciesResolution.bannedList
および teamcity.artifactDependenciesResolution.allowedList
) を指定して、アーティファクトをダウンロードするカスタムルールを設定します。禁止リストにパスを追加すると、許可リストに存在しない限り、このディレクトリへのアーティファクトのダウンロードが禁止されます。
アーティファクトの依存関係のためのスペースの自動割り当て
TeamCity は、アーティファクトのサイズに基づいて、アーティファクトの依存関係を解決するためにディスク領域を自動的に解放します。手動で構成する必要はありません。
Ant ビルドスクリプトを使用したアーティファクトの依存関係の設定
このセクションでは、ビルドスクリプト内で TeamCity ビルドアーティファクトをダウンロードする方法について説明します。これらの命令は、TeamCity の外部からアーティファクトをダウンロードするためにも使用できます。
ビルド間のアーティファクトの依存関係を処理するために、このソリューションは TeamCity UI で依存関係を構成するよりも複雑ですが、柔軟性を高めることができます。例: この方法で依存関係を管理すると、個人用ビルドを開始して、ビルドが依存関係と互換性があることを確認できます。
Ant ビルドスクリプトで依存関係を設定するには
1. Ivy をダウンロードしてください。
2. Ivy をビルドのクラスパスに追加します。
3. TeamCity リポジトリに関するメタ情報を含む ivyconf.xml
ファイルを作成します。このファイルには次のコンテンツが含まれます。
4. YOUR_TEAMCITY_HOST_NAME
を TeamCity サーバーのホスト名に置き換えます。
5. build.xml
を実行するディレクトリに ivyconf.xml
を配置します。
6. 同じディレクトリに、ダウンロードするアーティファクトと配置する場所を定義する ivy.xml
ファイルを作成します。例:
where:
YOUR_ORGANIZATION
はあなたの組織の名前に置き換えてください。YOUR_MODULE
は、アーティファクトが使用されるプロジェクトまたはモジュールの名前に置き換えます。BUILD_TYPE_EXT_ID
は、アーティファクトがダウンロードされたビルド構成の外部 ID に置き換えます。BUILD_REVISION
はビルド番号または以下の文字列のいずれかです:* latest.lastFinished
latest.lastSuccessful
latest.lastPinned
TAG_NAME.tcbuildtag
- TAG_NAME タグでタグ付けされた最後のビルド
ARTIFACT_FILE_NAME_WITHOUT_EXTENSION
ファイル名または拡張部分なしのアーティファクトの正規表現。ARTIFACT_FILE_NAME_EXTENSION
アーティファクトファイル名の拡張子部分。
7. build.xml
ファイルを変更し、アーティファクトをダウンロードするためのタスクを追加します。たとえば(Ant 1.6 以降に適用可能):
アーティファクトリポジトリは、基本認証によって保護されています。アーティファクトにアクセスするには、<ivy:configure/> タスクに資格情報を提供する必要があります。例:
ここで、TEAMCITY_HOST
は TeamCity サーバーのホスト名または IP アドレスです (ポートとサーブレットコンテキストは含まれません)。
USER_ID/PASSWORD
として、通常の TeamCity ユーザー (ユーザーはソースビルド構成のアーティファクトにアクセスするための対応する権限を持っている必要があります) のユーザー名 / パスワード、またはシステムプロパティ teamcity.auth.userId/teamcity.auth.password
のいずれかを使用できます。
ビルドレベル認証
システムプロパティ teamcity.auth.userId
と teamcity.auth.password
は、TeamCity サーバーでの認証に使用できる、自動的に生成されたビルド固有の値を格納します。値はビルドが実行されている間だけ有効です。この生成されたユーザーは、ビルド関連の操作を許可する権限が制限されています。ユーザーの主な目的は、認証を使用してビルドスクリプト内の他の TeamCity ビルドからアーティファクトをダウンロードすることです。
プロパティを使用すると、サーバーがビルドによってダウンロードされたアーティファクトを追跡できるため、実際のユーザー資格情報を使用するよりも望ましい方法です。アーティファクトがビルド構成アーティファクトの依存関係によって、または提供されたプロパティを使用してダウンロードされた場合、ビルドで使用される特定のアーティファクトは、ビルド結果ページの依存関係タブに表示されます。さらに、アーティファクトを取得するために使用されたビルドは、異なる clean-up ロジックを持つように構成できます。
関連ページ:
![](https://pleiades.io/icons/teamcity.png)
依存ビルド
TeamCity では、1 つのビルド構成は 1 つ以上の構成に依存できます。2 種類の依存関係を指定できます。スナップショットの依存関係、アーティファクトの依存関係、アーティファクトの依存関係は、あるビルドによって生成されたアーティファクトを別のビルドに取得するための単なる方法です。対応するスナップショットの依存関係がない場合、主にビルド構成がソースに関して関連していない場合に使用されます。例: あるビルドは他のビルドに再利用可能なコンポーネントを提供します。スナップショットの依存関係はビルド...
![](https://resources.jetbrains.com/help/img/teamcity/2023.11/create-build-configuration-button.png)
ビルド構成の作成と編集
このセクションには、TeamCity UI を介してビルド構成を作成および構成する方法に関する記事が含まれています。ビルド構成は、ビルドを開始し、UI でビルドのシーケンスをグループ化するために使用される設定のコレクションです。ビルド構成の例としては、ディストリビューション、統合テスト、リリースディストリビューションの準備、「夜間」ビルドなどがあります。ビルド構成はプロジェクトに属し、ビルドが含まれます。ホームページでビルド構成の詳細を確認し、設定ページでその設定を変更できます。一連のビルドごと...
![](https://resources.jetbrains.com/help/img/teamcity/2023.11/build-actions-menu.png)
ビルドの主なアクション
この記事では、TeamCity のビルドに適用できるアクションについて説明します。ビルドの実行:TeamCity では、ビルドを実行できます。自動的に、さまざまなビルドトリガーを使用します。手動で、オンデマンド。ビルドを手動で実行するには、画面の右上隅にある実行をクリックします。このアクションは、ビルド設定モードとビルド構成ホームモードの両方で使用できます。特定のビルド構成で実行ボタンが表示されない場合は、ビルドを開始するための十分な権限がないことを意味します。実行ボタンの横にあるコンテキスト...
![](https://resources.jetbrains.com/help/img/teamcity/2023.11/clean-up-inheritance.png)
TeamCity データのクリーンアップ
TeamCity のクリーンアップ機能により、古いビルドデータや不要なビルドデータを自動的に削除できます。サーバーのクリーンアップ構成は管理 | サーバー管理 | クリーンアップ設定で使用可能です。クリーンアップスケジュールの設定が可能で、一般的なクリーンアップ情報が表示されます。特定のプロジェクトに関連するクリーンアップルールは、プロジェクト設定 | クリーンアップ規則で構成されます。これらのルールは、どのデータをクリーニングし、何を保存するかを定義します。これらはプロジェクトまたはビルド構成...
![](https://resources.jetbrains.com/help/img/teamcity/2023.11/branches.png)
機能ブランチを使用した作業
分散バージョン管理システム(DVCS)の機能ブランチを使用すると、メインの開発とは関係なく機能に取り組み、機能のすべての変更をブランチにコミットし、機能の補完時に変更をメインのブランチにマージできます。このアプローチは、ソフトウェア開発チームに多くの利点をもたらします。ただし、専用のサポートがない継続的インテグレーションサーバーでは、ビルド構成の継続的な重複、可視性の低下、最終的にはプロセスの制御の喪失など、多くの問題も発生します。機能ブランチの TeamCity サポートは継続的に拡張されてお...
![](https://resources.jetbrains.com/help/img/teamcity/2023.11/dk-customRun-general.png)
カスタムビルドの実行
通常、ビルド構成ではビルドトリガーを使用して、必要なスケジュールに従って、または TeamCity がソースコード内の新しい変更を検出したときに新しいビルドを開始します。これらの自動的にトリガーされるビルドに加えて、TeamCity ではビルドを手動で実行し、必要に応じて設定をカスタマイズすることもできます。つまり、新しいプロパティの追加または既存のプロパティの変更、特定の変更の選択、ビルドのスケジュール、ビルドを実行するエージェントの選択などを行うことができます。TeamCity には、カスタ...