TeamCity 2020.2 ヘルプ

TeamCity 2020.2 の新機能

新しいヘッダー

TeamCity 2020.2 には、クラシック UI とエクスペリメンタル UI の両方に最新のヘッダーが付属しています。

New header 2020.2

Python サポートはすぐに使用できます

TeamCity 2020.2 には、新しい Python ランナーがバンドルされています。ビルドエージェントで Python を自動的に検出し、サポートされているすべてのプラットフォームで Python スクリプトを実行できるようにします。

現在廃止されている Python ランナー(英語)プラグインと比較すると、新しいランナーは TeamCity と緊密に統合され、次のような追加の可能性をもたらします。

  • 自動テストレポート(unittest および pytest 経由)およびインスペクション (flake8 と pylint 経由)

  • 仮想環境の使用

  • Docker コンテナー内でビルドステップを起動する

Bundled Python build runner

古いプラグインを使用して Python プロジェクトを実行していた場合は、それぞれのビルドステップをバンドルされたランナーに切り替えることを強くお勧めします。新しいランナーは追加の設定を提供するため、これらの手順は手動で再構成する必要があります。

新しいランナーを構成する方法を参照してください。

エージェントレスのビルド手順

このリリース以降、ビルドの最後のステップは、外部ソフトウェアでビルドエージェントなしで終了できます。

通常、実行中のビルドは、すべてのステップが完了するまでビルドエージェントを占有します。場合によっては、ビルドは、ビルドエージェントの外部で外部システムによって実行されるプロセスを待機する必要があります。例:最後のステップがサードパーティソフトウェアを介したデプロイを担当している場合、エージェントはこのステップが終了するまで何もしません。

これで、ビルドを現在のエージェントから切り離すことができます。このエージェントは他のビルドで使用できるようになりますが、ビルドは「エージェントレス」で実行され続けます。モード。

エージェントをデタッチするには、ビルドで ##teamcity[detachedFromAgent] サービスメッセージを送信する必要があります。
エージェントレスビルドの進行状況を報告し、外部プロセスが終了したら終了するために使用できる専用の RESTAPI エンドポイントがあります。それらの詳細については、ドキュメントを参照してください

同時に実行するエージェントレスビルドの数には制限があります。これは、インストールで許可されているエージェントの最大数と同じです。このように、10 個のエージェントライセンスがある場合、最大 10 個のエージェント最大 10 個のエージェントレスビルドを並行して実行できます。
制限を超えると、実行中のエージェントレスビルドの一部が終了するまで、ビルドをエージェントから切り離すことができません。

GitHub.com、GitHub Enterprise、GitLab.com、GitLab CE / EE、BitbucketCloud による認証

これで、ユーザーは次の外部アカウントを使用して TeamCity で認証できます。

この統合には、VCS ホスティングプロバイダー側で専用アプリケーションを作成し、TeamCity で接続する必要があります。接続を構成する方法の詳細な手順については、こちらを参照してください
リストされている各プロバイダーで認証を有効にするには、システム管理者はそれぞれの認証モジュールをアクティブ化する必要があります。これらのモジュールのいずれかがサーバーで有効になっている場合、ユーザーにはログインフォームの上にそのアイコンが表示されます。

Authentication with VCS hosting provider

外部ユーザーとしてサインインするには、このアイコンをクリックし、リダイレクト後、外部アカウントで TeamCity アプリケーションを承認する必要があります。成功すると、TeamCity に再度サインインします。
外部アカウントのメールアドレスを持つユーザーが TeamCity に登録されている場合、このユーザーとして認証されます。それ以外の場合、TeamCity は新しいユーザープロファイルを作成します(このオプションを手動で無効にしない限り)。
TeamCity によって自動的に認識されるように、ユーザーは自分のプロファイルを設定とツールの外部アカウントに接続することもできます。

管理者は、TeamCity ユーザーを外部アカウントにマップし、メンバーがサーバーにアクセスできるプロバイダーのグループ / 組織 / ワークスペースを制限できます。

認証モジュールを有効にして管理する方法を学びます。

Bitbucket クラウドプルリクエストのサポート

TeamCity は、GitHub、GitLab、Azure DevOps、および Bitbucket サーバーでのプルリクエストの監視をすでにサポートしています。そして今– Bitbucket クラウドで。

Bitbucket Cloud pull requests

プルリクエストを Bitbucket クラウドリポジトリに送信すると、TeamCity はそれを検出し、新しいビルドを実行して、プルリクエストの結果を表示します。これを機能させるには、プルリクエストビルド機能と VCS トリガーを構成する必要があります。
この機能は、Bitbucket クラウドでは他の VCS とは少し異なる動作をすることに注意してください。Bitbucket Cloud はプルリクエストごとに専用のブランチを作成しないため、TeamCity はプルリクエストのソースブランチでビルドを実行し、ソースリポジトリのみを監視します(フォークはサポートされていません)。

詳細を参照してください。

Commit StatusPublisher での JetBrains スペースのサポート

ステータス発行者のコミットビルド機能は JetBrains スペースと統合できます。この機能を使用すると、TeamCity ビルドは、ステータスを JetBrainsSpace プロジェクトにリアルタイムで自動的に公開できます。

JetBrains Space support in Commit Status Publisher

この統合を構成する方法を参照してください。

実験的な UI の更新

実験的な UI は進行中の作業です。開発の初期段階で変更を導入しているため、新しい機能をすでに利用できます。各リリースでは、既存の実験ページを磨き、新しい UI ですべての重要なクラシック機能を再現します。私たちのロードマップは、ユーザーのフィードバックに大きく依存しています。
バージョン 2020.2 では、テストヒストリーページとビルドキューページを追加し、ビルドログに全文検索を実装し、ビルド結果の依存関係タブを改善しました。

おなじみの機能のいずれかが欠落している場合は、mammoth.pngボタンを使用して実験ページをクラシック UI に切り替えるか、設定とツールでサーバーの実験 UI を完全にオフにすることができます。

実験テスト履歴ページ

このリリースでは、需要の高いテストヒストリーページが新しくなりました。これで、クラシックモードに切り替えることなく、詳細な検定統計量を確認できます。

Experimental Test History page

ビルドログでの全文検索

UI に既に読み込まれている量に関係なく、ビルドログを検索できるようになりました。

Search in experimental build log

更新された依存関係の表示

ビルドチェーンタイムラインの実験的な UI 表現で、キューに入れられたビルドを表示するようにという多くのリクエストを受け取りました。このリリースでは、ビルドチェーンディスプレイを更新して、より有益なものにしました。

  • 依存関係 | タイムラインビューには、キューに入れられたものを含む、現在のビルドのすべての依存関係が表示されます。

  • 依存関係 | チェーンビューには、フルビルドチェーンが表示されます。従来の UI と同様に、現在のビルドに依存するすべてのビルドを表示し、現在のビルドをそれらにプロモートできます。ビルドがコンポジットの場合、このビューから直接グループ化することもできます。

Experimental build chain

実験的な UI でのプラグインのサポート

これで、最新の Web テクノロジーとさまざまなフレームワークを使用して、実験的な UI のプラグインを作成できます。詳細については、このブログ投稿(英語)を参照してください。

実験的なビルドキューページ

ビルドキューの新しい表現に積極的に取り組んでいます。まだ進行中で、デフォルトではまだ表示されていませんが、画面の右上隅にあるテスト管アイコンをクリックすると、すでに切り替えることができます。

新しいサイドバーは、プロジェクトおよびエージェントページのユーザーにとって非常に役立ちます。現在、キューページでも使用できます。これは、多くのエージェントプールがある大規模なインストールで最も役立ちます。

キュー内の任意のビルドをクリックして、その詳細を表示することもできます。

Experimental build queue

将来のリリースでは、新しいキュー表現を洗練し、実験的な UI でデフォルトで有効にする予定です。

カスタマイズ可能なクリーンアップスケジュール

cron のような式のサポートにより、TeamCity サーバーのクリーンアップがより柔軟になります。スケジュールをカスタマイズして、クリーンアップが必要な規則で開始されるようにすることができます。たとえば、週末や 1 日 2 回です。

Cron expressions in clean-up

クリーンアップの頻度が高すぎると CPU に大きな負荷がかかる可能性があり、クリーンアップの頻度が低すぎると時間がかかり、ゴミが蓄積する可能性があることに注意してください。クリーンアップスケジュールのバランスを保つことをお勧めします。ほとんどの場合、毎日のクリーンアップで十分ですが、負荷の高いインストールでは、より頻繁にクリーンアップを実行する必要があります。

期間限定のアクセストークン

TeamCity は、時間制限のあるアクセストークンを生成できます。これらのトークンをスクリプトまたはその他の RESTAPI リクエストで使用して、TeamCity サーバーへの一時的なアクセスを許可できます。トークンの期限が切れると、TeamCity は自動的にアクセスを取り消します。

新しいトークンを追加するには、設定とツール | アクセストークンに移動します。

Temporary access tokens

セカンダリノードでのプロジェクト設定の編集

TeamCity 2020.2 は、セカンダリノードに新しい責任を追加します。ノードに付与すると、UI アクション(実行、停止、タグ付け、ビルドのコメントなど)が可能になります。サポートされている UI アクションリストには、プロジェクトの編集と構成のビルドも含まれるようになりました(クラウドプロファイルの編集など、いくつかの制限があります)。
この責任を無効にすると、セカンダリノードが読み取り専用モードに切り替わります。

アップグレードノートも参照してください。

外部ストレージのディスク使用量の監視

ビルドアーティファクトをクラウド(たとえば、Amazon S3)に保存することを好むユーザーが増えています。ただし、以前はそこに保存されているデータの量を確認することはできませんでした。

ディスクの使用状況レポートは、外部アーティファクトストレージをサポートするようになりました。構成された各ストレージまたはそれらすべてに一度に保存されたデータの量が表示されます。さらに、ローカルストレージ用に複数のアーティファクトディレクトリが構成されている場合は、ディレクトリごとにこのレポートを個別に表示できるようになりました。

管理 | ディスクの使用状況ページで、検出されたストレージを切り替えて、詳細なレポートを表示できます。

External storage in Disk Usage report

カスタム設定でビルドを識別する

「カスタム」の区別が簡単になりました。通常のものから構築します。カスタムパラメーターまたはアーティファクトの依存関係を使用してビルドが実行された場合、または最新のコミットで実行されなかった場合、TeamCity はそのようなビルドを視覚的にマークします。ビルドリストに、このビルドの反対側にあるそれぞれのアイコンとヒントが表示されます。

Custom build hint

ビルド結果:

Custom build hint

ヒントのリンクをクリックして、ビルド結果の関連タブを開きます。

再試行に成功した後、失敗したテストをミュートする

一部のビルドは、失敗した場合にテストを再試行できます。これは、不安定なテストに最も便利です。このようなテストは、同じソースリビジョンに適用すると、失敗と成功が交互に発生する可能性があるため、ビルドステータスへの影響を除外することをお勧めします。
これで、ビルドでテストの再試行が有効になっている場合、同じビルドの実行中に最終的に成功すると、TeamCity は失敗したテストをミュートします。このテストはビルドステータスに影響を与えず、他に問題がなければビルドは正常に終了します。

Muted by test retry

詳細については、ドキュメントを参照してください。

その他の改善

  • プルリクエスト用のソースブランチフィルター
    TeamCity は、ターゲットだけでなくソースブランチによってプル要求をフィルタリングできます。これにより、特定のドラフトブランチを監視の範囲から簡単に除外できます。
    TeamCity はソースブランチでプル要求を直接監視するため、このフィルターは Bitbucket クラウドには適用されないことに注意してください。

  • ビルドステップ間で NuGet パッケージを渡す NuGet パッケージを公開してから、そのコンテンツを 1 つのビルド内で使用する必要がある場合は、ビルドの終了時ではなく、時間どおりに公開およびインデックス付けされることを保証する必要があります。以前は、NuGet 公開ステップを使用する必要がありました。このリリース以降、ビルドステップで代わりに ##teamcity[publishNuGetPackage] サービスメッセージを送信できます。これにより、NuGet パッケージは、現在のビルドステップの最後に、構成されているすべての NuGet フィードで公開され、次のビルドステップで使用できるようになります。

  • エージェント Docker コンテナーのより高速なコールドスタート
    このバージョン以降、TeamCity エージェント Docker イメージは、完全なエージェントディストリビューションに基づいています。完全なエージェントには、バンドルされているすべてのプラグインが含まれています。これにより、エージェント全体がすべてのプラグインをサーバーと同期する必要がないため、エージェントのコールドスタートが大幅に高速化されます。起動すると、サーバーにインストールされている外部プラグインまたはツールのみがダウンロードされます。
    この改善は、Docker イメージがサーバーのバージョンと一致する場合にのみ有効であることに注意してください。

  • より簡単な PerforceSSH ルート構成
    プロジェクトの VCS ルートが SSH 経由で Perforce に接続する場合、TeamCity は自動的に信頼できる接続を確立します。Perforce 接続をテストするか、ビルドエージェントが Perforce からチェックアウトするたびに、p4 trust コマンドが送信されるようになりました。

  • ビルドごとに公開されるアーティファクトの数を制限する
    これは、複数のビルドが多数のアーティファクトを並行して公開する場合に、メモリ消費とパフォーマンスの問題を防ぐのに役立ちます。
    この数は、すべての新規インストールで 1000 に設定されます。既存の TeamCity インストールのアップグレード時に、この数は無制限のままになります。管理 | サーバー管理 | グローバル設定の値を制限できます。この制限では、非表示のアーティファクトは考慮されないことに注意してください。

  • 複合ビルドの実行タイムアウト
    複合ビルドが開始できないビルドで構成されている場合(たとえば、互換性のあるエージェントがない場合)、この複合ビルドは手動で終了するまで永久に実行される可能性があります。これで、このようなビルドの実行タイムアウトを設定して、長時間起動できなくなった後に自動的に失敗するようにすることができます。

  • S3 パスプレフィックスのサポート
    AmazonS3 アーティファクトストレージを設定するときにパスプレフィックスを設定できるようになりました。これにより、すべての TeamCity プロジェクトに同じ S3 バケットを使用し、プレフィックスベースのアクセス許可を構成できます。

  • プルリクエストアイコンを更新
    ビルド結果でプルリクエストを表すアイコンが大きくなり、プルリクエストの状態に応じて色が変わるため、ステータスをすばやく識別できます。

  • 安全でない Tomcat 接続構成に関するヘルスレポート
    サーバーが TeamCity サーバーへの HTTPS アクセスを提供するリバースプロキシの背後にインストールされている場合、TeamCity は secure="true " および scheme=" https" 属性が Tomcat 接続に存在するかどうかをチェックするようになりました。これらの属性が欠落している場合、TeamCity はそれぞれのヘルスレポートを表示します。

  • デフォルトの Gradle ビルドファイル値はありません
    以前は、Gradle ランナーのファイルのビルドフィールドはデフォルトで build.gradle に設定されていました。一部のユーザーはビルドファイルのカスタム名に依存し、Gradle に選択するファイルを決定させることを好むため、このデフォルト値を削除しました。
    ビルドファイルとして build.gradle を使用する場合、すべてがこの更新前と同じように機能し続けます。

  • RESTAPI の更新 :
  • .NET ビルドランナーは、以前のバージョンの Visual Studio および MSBuild をサポートするようになりました。現在サポートされているバージョンは、Visual Studio2010 以降、MSBuild 4 / 12 以降です。

  • バンドルされているすべてのツールアップデートを確認するには、アップグレードノートをお読みください。

  • バージョン 2020.2 には、さまざまな機能(たとえば、カスタム実行ダイアログ)で最大 30 のパフォーマンス修正が含まれています。

修正された課題

TeamCity 2020.2 リリースノート(英語)を参照してください。

アップグレードノート

アップグレードする前に、2020.1.x と比較したバージョン 2020.2 の重要な変更について読むことを強くお勧めします。

以前のリリース

ロードマップ

将来のアップデートについては、TeamCity ロードマップを参照してください。

最終更新日 :

関連ページ:

サービスメッセージ

サービスメッセージは、ビルドに関するコマンド / 情報をビルドスクリプトから TeamCity サーバーに渡す特別に構成されたテキストです。TeamCity、それらはビルドの標準出力ストリームに書き込まれる必要があり、ビルドステップから出力またはエコーされますによって処理されます。1 行に 1 つの...

TeamCity と VCS ホスティングサービスの統合

GitHub、GitHub Enterprise、Bitbucket クラウド、GitLab.com、またはGitLab CE / EEに組織アカウントがある場合は、TeamCity をこれらのソースコードホスティングサービスに接続して、組織ユーザーが新しいプロジェクト、GitまたはMercuria...

プルリクエスト

プルリクエストビルド機能を使用すると、プルリクエスト * 情報を自動的にロードし、GitHub、Bitbucket サーバー、Bitbucket クラウド、GitLab、およびAzure DevOpsのプルリクエストブランチでビルドを実行できます。* または、GitLab の場合はリクエストをマー...

VCS トリガーの設定

TeamCity が設定されたVCS ルートで新しい変更を検出するたびに、VCS は自動的に新しいビルドを開始し、保留中の変更にその変更を表示します。ビルド構成に追加できる VCS トリガーは 1 つだけです。ビルド構成に保留中の変更があると、デフォルト設定の新しい VCS トリガーがビルドをトリガ...

ステータス発行者のコミット

コミットステータスパブリッシャーは、TeamCity がコミットのビルドステータスを外部システムに自動的に送信できるようにするビルド機能です。この機能は、TeamCity にバンドルされているオープンソースプラグインとして実装されます。サポートされているシステムは次のとおりです。JetBrains

TeamCity テスト運用 UI

バージョン 2019.1 では、TeamCity はクラシック UI の代替として実験的な UI オプションを導入しました。私たちの実験的な UI は進行中の作業です。開発の初期段階で機能の変更を提示するため、新機能をできるだけ早く利用できます。私たちのビジョンとフィードバックに基づいて、常に新しい...