DebianリポジトリとしてのTeamCity

...またはTeamCityを使用して*.debパッケージなどをビルドします。

私は、 tcDebRepositoryモジュールを知ることで記事を書きたいと思いました 。 「今すぐプラグインすれば、すべてが魔法のように機能する」と単純に信じていました。 いつものように、それは機能せず、最終的に特定の経験が蓄積されました。それを体系化したいと思いました。

この記事は、 TeamCityの基本を紹介するものではなく、読者がTeamCityとDebian GNU / Linuxインフラストラクチャの両方に既に精通していることを前提としています。 継続的インテグレーションが何であるかをすでに想像しているが、 TeamCityを手にしたことがない場合は、おそらくここにいます 。 Debianでのパッケージのビルドについては、 Debian New Maintainers 'Guideで読むことができます。

ゲームの場合（誰かが結果を再現したい場合）、彼らはDebian 8.0（Jessie）を実行しているTeamCity 10サーバーと3つのエージェントを使用しました 。 3エージェント-これは、 TeamCity Professionalの場合の制限です。 以下で説明するすべてのものは、 Astra Linuxなど、 Debian GNU / Linuxに基づいた他のディストリビューションに簡単に転送できると思います。

計画

かなりarbitrary意的な方法で、実験用に4つのパッケージを選択しました。

• autotools-dev （ Git ）
• bash （ Git 、 Bazaar ）
• debhelper （ git ）
• dpkg （ git ）

ビルド構成の数に対するProfessionalライセンスの制限を考えると、最大20個のパッケージを「ダイヤル」できました。

準備する

TeamCityは公式サイトからダウンロードされます。 TeamCity自体に加えて、 各エージェントマシンにビルド必須パッケージをインストールする必要があります。また、4つのパッケージすべてのアセンブリに必要な依存関係（カテゴリから） build-depends build-depends-indep ）。 これにより、ビルドの依存関係の問題が最小限に抑えられます（必ずしも排除されるわけではありません）。

Debian GNU / Linuxのパッケージタイプ

パッケージは、他の機能の中でも、「ネイティブ」（ ネイティブ ）と外部（ 非ネイティブ ）（ 詳細 ）に分けられます。 ネイティブパッケージ（ autotools-dev 、 debhelper 、 dpkg ）は通常Debianプロジェクトの一部として開発され、ソースコードにはすでにアセンブリに必要なメタ情報（ソースツリーのルートのdebian/ディレクトリ）が含まれています。

外部パッケージ（ bash ）の違いは、ソースコードがDebianに結び付けられていないことと、メンテナンスエンジニア（ロシア語のドキュメントではこれは「Debian開発者」と呼ばれ、英語では単に「maintainer」と呼ばれます）パッチ（これはdebian/ディレクトリのまさに内容です）。

一般設定

収集するバイナリパッケージは、 TeamCityの用語では「 成果物 」です。 したがって、次のアセンブリの最後の最終行で、 アーティファクトパスを指定して、期待するものを指定する必要があります 。

アーティファクトpkgname.orig.tar.{gz,bz2,xz}およびpkgname.debian.tar.{gz,bz2,xz} 、ネイティブパッケージ用に作成されません。

ソースコードをTeamCityに接続する

ほとんどの場合、この手順だけは複雑ではありません。ビルド構成設定に移動して、バージョン管理システムの新しいルート （VCSルート）を追加するだけです。 「ネイティブ」パッケージの場合、この操作は通常1回、外部のパッケージでは2回実行する必要があります（ただし、開発者（Debianプロジェクト外）と保守エンジニアの両方が同じDVCS（ Git 、 Bazaar ）を使用し、コードは、メタ情報とパッチのマージの競合を引き起こさずに、あるリポジトリから別のリポジトリへと絶えずさまよっています。

唯一の機能は、この場合のアーティファクトはソースコードツリー（上記の1つのディレクトリ）の外部で収集されるため、たとえばdpkgパッケージのソースコードが現在の作業ディレクトリにロードされないようにチェックアウトルールを構成する必要がありますが、同じ名前のパッケージ内のサブディレクトリ、つまりdpkg/ これは、 チェックアウトルールに 1行追加することで実現されます 。

 +:.=>dpkg 

最終的には次のようになります。

これで、バージョン管理設定に戻らずにVCSトリガーを追加できます。

Bazaarとの統合

「しかし、 bashをビルドするにはBazaarとの統合が必要であり、標準のTeamCity配信はこのシステムをサポートしていません！」 -気配りのある読者が言うでしょう、そして彼は正しいでしょう。 さらに、 残念ながらTeamCityでは、 bzr::http://bazaar.launchpad.net/~doko/+junk/pkg-bash-debianようなGit URLを追加できません-JGitには制限が多すぎます。

Bazaarをサポートする外部モジュールがありますが、少なくとも2つの重大な欠陥があります。

• エージェント側のチェックアウトはサポートされていません。
• モジュールはbzr xmllsおよびbzr xmllogの機能に依存しているため、 Bazaarの標準配信では不十分です 。これらはビルドプロセス中にのみ検出されます。

TeamCityサーバーはWindowsで動作していたため、 Bazaarをサーバー側にインストールするという楽しい冒険を放棄し、 bash代わりにbash コマンドラインランナーと次のスクリプトを使用して、別のビルドステップ（貧しい人々のためのBazaar統合）を追加しましたシェル：

 #!/bin/bash # # vim:ft=sh: # export LANG=C export LC_ALL=C set -e rm -rf bash/debian bzr branch http://bazaar.launchpad.net/~doko/+junk/pkg-bash-debian bash/debian major_minor=$(head -n1 bash/debian/changelog | awk '{print $2}' | tr -d '[()]' | cut -d- -f1) echo "Package version from debian/changelog: ${major_minor}" tar_archive=bash_${major_minor}.orig.tar rm -f ${tar_archive} ${tar_archive}.bz2 # +:.=>bash checkout rule should be set for the main VCS root in TeamCity tar cf ${tar_archive} bash tar --delete -f ${tar_archive} bash/debian # Required by dpkg-buildpackage bzip2 -9 ${tar_archive} 

このようなアプローチでは、1つのソースツリー（2つのうち）で変更を「確認」し、それらが（変更）表示されたときに自動的にアセンブリを開始できませんが、最初の実験では十分です。

NB！ コマンドラインランナーはスクリプトコードの構文を強調できないため、 Mozilla FirefoxおよびSeaMonkeyブラウザーのユーザーには、拡張機能It's All Text！をお勧めします。 、外部エディタでテキストフィールドの内容を編集できます。 VimまたはEmacsを接続して、構文の強調表示、オートコンプリート、 チェスと詩人 。

組み立て：セットアップ

ビルドするには、既におなじみのコマンドラインランナーを使用するだけで十分です。このコマンドラインランナーはdpkg-buildpackageを呼び出します。 -ucおよび-us -ucは、パッケージのデジタル署名を作成したくないことを意味します。 それでも必要な場合は、対応するGnuPGキーのペアを各エージェントにダウンロードする必要があります。

また、 dpkg-buildpackageは、現在の作業ディレクトリではなく、サブディレクトリ（ソースコードツリーがアップロードされる場所）の同じ名前のパッケージで実行する必要があることに注意してください。 バージョン管理が設定されている場合、ディレクトリ名を手動で入力せずに、マウスを1回クリックするだけで[作業ディレクトリ]フィールドに入力できます。

アセンブリ：問題解決

コード品質

奇妙なことですが、コードの品質（より正確には、開発のスタイル）は、継続的な統合の実装への道で重大な問題になる可能性があります。 経験的に、 bashの場合、2つのコードツリーのバージョンは同期していません。メインツリーの最後のコミットはバージョン4.4に対応していますが、 debian/changelogファイルはバージョン4.3でほぼ2年前に停止し、一方のバージョンのコードはもう一方のバージョンのメタ情報を持ちます集まってはいけません。 それでは、メインツリーにbash-4.3ブランチが必要です。

依存関係

最初のビルドを開始すると、 dpkg-buildpackageリターンコード3での作業を終了したことがわかります。

アセンブリプロトコルを表示した結果、いくつかの依存関係がまだ欠落していることがわかりました。

ただし、ここでは必要なすべてのものを（すべてのエージェントに）インストールし、 dpkg-buildpackageは同じコードで終了します。 問題は何ですか？ ここにはいくつかのニュアンスがあります。

• ほとんどの場合、 Debian不安定版またはDebian実験版からソフトウェアをビルドします。 この場合、アセンブリに必要な依存関係を満たすために、 TeamCityエージェントはDebian不安定版またはDebian実験版を実行している必要があります（そうでない場合、 dpkg-buildpackageは依存関係の安定バージョンが「古い」ことを「誓います」）。 エラーを抑制するには、 -dスイッチを追加するだけで十分な場合があります。
  

   dpkg-buildpackage -uc -us -d 

• 廃止された依存関係の特殊なケースは、現在システムにインストールされているよりも新しいバージョンのGNU Autotoolsによって作成されたconfigureスクリプトです。 dpkg-buildpackageこの状況を診断することdpkg-buildpackageできません-代わりに、ビルドプロトコルでは、 m4マクロの欠落に関する不可解なメッセージが表示されます。 解決策は、現行バージョンのGNU Autotoolsを使用してconfigureスクリプトを再作成することです。 ビルドの最初のステップとして次のコマンドを追加するだけです。
  

   autoreconf -i 

壊れた単体テスト

それでも自分を欺いてパッケージを収集したい場合は、変更された環境でdpkg-buildpackageを実行するだけで十分です。

 DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -uc -us 

自己欺ofの他の方法については、 こちらをご覧ください 。

フィニッシュライン

地獄のすべての円が渡された後、次のアセンブリが成果物の作成で終了したことがわかります。

パッケージバージョンの増分ごとに1つのアセンブリのアーティファクトの数を増やしたくない場合（最終的にはdpkg_1.18.16_i386.deb 、 dpkg_1.18.17_i386.debおよびdpkg_1.18.18_i386.deb広い範囲を提供します）、作業ディレクトリの内容は各アセンブリの前に選択的にクリーニングします。 これは、引数として悪名高いアーティファクトパスを使用してrm -rfを呼び出すことdpkg-buildpackage直前に手動で実行できますが、より良い方法があります-愛情のこもった名前「Mop」を持つ標準のTeamCityモジュール。 これは、設定がどのように見えるかです（ここで重要なのは「次のビルド開始前」です）：

ただし、 Swabraモジュールが正しく構成されている場合、アセンブリプロトコルの対応するフラグメントは次のようになります。

今こそ、Debianリポジトリをセットアップするときです。 これは、 tcDebRepositoryモジュール設定にアーティファクトフィルターを追加することで実現されます 。 いくつかの不便な点は、各構成（ソフトウェアパッケージを読む）に対して、以前のフィルターと実質的に同一の新しいフィルターを追加する必要があることです。

既存のアーティファクトはインデックス化されないため、Debianリポジトリの最終セットアップ後、各構成で少なくとも1つのアセンブリを通過する必要があります。 この後、予想が来ます：

アーキテクチャパッケージディレクトリ

および利用可能なパッケージのリスト

リポジトリを/etc/apt/sources.list追加すると、クライアント側からすべての同じパッケージを確認できます。

パッケージにデジタル署名がないことがわかります

NB！ 複数のアーキテクチャ（ i386 、 x32 、 amd64 、 arm ）でビルドする場合、1つのパッケージに対応し、エージェントの要件が異なる複数の個別のビルド構成が必要です。または、 VCSトリガーに加えて、「トリガービルドオン有効で互換性のあるすべてのエージェント "：

しばらくすると、 dpkgプロジェクトが活発に開発されていることがわかりますが、残りの参加者は竹を吸っているようです。