Clever Geek Handbook

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つのパッケージを選択しました。









ビルド構成の数に対する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つの重大な欠陥があります。









画像







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



ブランチが必要です。







これで、コミットツリーを見て楽しむことができます。

画像







  • ここに、 bash-4.3-rc2



    と（以下では見えない） bash-4.3-rc1



    bash-4.3-testing



    ブランチがありbash-4.3-rc2



    -そして、突然壊れます。 バージョン履歴を信じている場合は、 bash



    4.3のリリースは行われていません。
  • 同時に、数日後、 bash-4.3



    タグを使用してmaster



    ブランチにコミットが表示されます。これには、 mergeやcherry-pickなどの操作が先行していません。
  • コミットの履歴と内容を簡単に見ると、すべての開発が1人のローカルブランチで実行され、 savannah.gnu.orgでの git push



    が定期的に発生し、 git merge --squash -s ours



    （コミットごとに）信じられないほど長く、読みにくいdiff



    ）。
  • 「 Bash-4.3 patch XY



    」コミット（バージョン4.3の合計46個のパッチ）はmaster



    配置され（ bash-4.3-testing



    にはありません）、3週間後にbash-4.4-beta2



    ラベルがmaster



    ブランチに表示されます。 これは、「 bash



    4.3 plus patch」の最後の安定状態は、残念ながら、どこにでもないことを意味します。 TeamCityでは、タグ（「 ブランチ仕様でタグを使用できるようにする 」フラグ） を使用してビルドできます。これは最終的に行われました。


要約：







  • 私が見たのは、従来のブランチ作成スキームやgit-flowとは異なります。
  • はい、タグによるアセンブリは継続的インテグレーションの全ポイントを無効にすることは承知していますが、 bash



    開発者とはまた別のbash



    話します。


依存関係



最初のビルドを開始すると、 dpkg-buildpackage



リターンコード3での作業を終了したことがわかります。







画像







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







画像







ただし、ここでは必要なすべてのものを（すべてのエージェントに）インストールし、 dpkg-buildpackage



は同じコードで終了します。 問題は何ですか？ ここにはいくつかのニュアンスがあります。









壊れた単体テスト



それでも自分を欺いてパッケージを収集したい場合は、変更された環境で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



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







幸せな建物！

画像







More articles:


All Articles