現在、既存のカスタム継続ビルド システムを TeamCity を使用するように変換中です。これは、ほとんどのビルド シナリオでうまく機能するように見えますが、1 つだけです。
特定のツール チェーン セットで構成された Eclipse を使用してビルドするようにセットアップされたハードウェア プロジェクトがあります。開発者は IDE を実行し、Eclipse ビルド ランナーがないため、TeamCity は Python スクリプトを使用してコマンドライン ランナーからプロジェクトをビルドします。
TeamCity のビルド プロセスは次のとおりです。
- Eclipse ワークスペースの内容を削除します。
- すべての Eclipse プロジェクトをワークスペースにインポートします。
- ワークスペースを構築します。
このアプローチの問題点は次のとおりです。
- Eclipse 用のビルド ランナーはありません。スクリプトは機能しますが、スクリプトの開発と保守にはオーバーヘッドがあります。これこそが、私たちが逃げようとしているものです。
- 出力の TeamCity 解析はありません (gcc および eclipse)。Eclipse の出力をファイルにリダイレクトする必要があります。Eclipse プロセスが終了したら、適切な TeamCity サービス メッセージを stdout に挿入するために、エラー、警告、進行状況などについてファイルを解析します。繰り返しますが、この種のオーバーヘッドは、まさに私たちが回避しようとしているものです。
リリースからわずか数日後に Eclipse ビルド ランナーがない場合、TeamCity で Eclipse ワークスペースをロードしてビルドするためのより良いメカニズムはありますか?
コマンドライン ランナー スクリプト ソリューションを考えると、エラーや警告などをキャプチャして表示するためのより良いメカニズムはありますか?