最初の部分では、Debian / Ubuntu用の新しいMidnight Commanderファイルマネージャーバイナリパッケージビルドサービスを紹介しました。 コメントは、環境自体の技術的な説明がないことを正しく指摘しており、コードが神の形になったらすぐに詳細を投稿することを約束しました。 2週間が経ち、機能を安定させ、コードをくしとめるために少し時間がかかりました（それでもひどいですが、意図したとおりに動作するようです）。
私は特にソースコードをトピックに含めません、それらの多くがあります、そして、私の意見では、記事は過負荷になります。 興味のある方は誰でもgooglecodeからダウンロードできます。
組立環境
アセンブリ環境は、いくつかのシェルスクリプトで構成されています。
- contrib / mc - release - builds.sh -CRONジョブとして実行され、新しいリリースのアセンブリ、または既にリリースされたリリースの再構築を制御するスクリプト。
- contrib / mc-nightly-builds.shは、CRONジョブでもあり、夜間スライスを作成するスクリプトです。
- contrib / prepare -environment.sh-サーバー固有の環境変数を初期化するスクリプト（特に、環境変数はSSHおよびGPGエージェントの操作用にエクスポートされます）
- contrib / local-repo -update-リポジトリを更新するスクリプト。現在、apt-ftparchiveを放棄してrepreproを試すことを考えています。
- contrib / pbuilder-アセンブリターゲット構成。そのうちの1つ（contrib / pbuilder / buildbot）を使用して、ソースまたはGITからパッケージを準備します。
- contrib / apt-ftparchive - apt-ftparchiveを動作させるための私の設定（誰かに役立つかもしれません）
次は、アセンブリ環境自体を構成するスクリプトです。
- build - mc - from - git.sh-ソースまたはVCS（システムコア）からパッケージをビルドします
- buildbot.sh-前のスクリプトのラッパー。これは、クラウン、ユーザー、およびアセンブリ環境のカーネルのタスク間の中間リンクです。
- initial -build.sh-時代錯誤。これは私の自然な怠lazのおかげです。 単一のbuildbotユーザーをpbuilder（buildbot）アセンブリターゲットに追加します。
build-mc-from-git.sh
前述したように、これはビルド環境の最も重要な部分です。 リリースのアセンブル/再アセンブルとGITからの夜間スライスのアセンブルの2種類の操作を実行します。 リリースビルドが選択された場合、スクリプトは次のようになります。
- リポジトリからcontrib / debian /ディレクトリのローカルコピーを更新します。これはパッケージのビルドに必要です（パッケージのビルド時にはdh_makeは使用されません）
- ソースアーカイブをアンパックします。ソースアーカイブは、上位のスクリプトまたはユーザーによって引数の1つとしてスクリプトに渡されます。
- ソースコードが「そのまま」であるかどうかを確認します。 これを行うには、展開されたソースがあるディレクトリで、おなじみの一連のアクションが実行されます。
[ -x ./autogen.sh ] && ./autogen.sh ./configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib/mc make make install DESTDIR=/tmp/install
この手順でエラーが発生しない場合、パッケージアセンブリの問題は、パッケージのdebian固有の部分（VCSのcontrib / debian /ディレクトリ）を修正する必要があることを示しています - VCSのローカルコピーからソースにdebian /ディレクトリをコピーし、ソースのバージョンのローカル変更ログがあるかどうかをチェックし（パッケージの新しいリビジョンではなく、新しいリリースがビルドされている場合）、存在する場合は、VCSからの変更ログをローカルのものに置き換えます。
- バージョンやリビジョン番号をインクリメントし、dpkg-buildpackage -rfakeroot -us -ucを呼び出してパッケージの構築を開始します
- Debianポリシーに準拠しているかどうか、lintianでパッケージをチェックします。 lintianの出力は別のファイルに保存されます。 （最近、ナイトリービルドのマニュアルページでエラーをキャッチし、アップストリームにパッチを送信するのに役立ちました）
ナイトスライスのアセンブリは、ソースがGITリポジトリから形成され、バージョンインクリメントコードが異なるという点でのみ異なります。 リポジトリのmasterブランチに変更がなかったことをスクリプトが検出すると、アセンブリが中断されます。
buildbot.sh
このスクリプトはbuild-mc-from-git.shを呼び出し、成功した場合はpiupartsで追加のバイナリパッケージチェックを行い、エラーがなければターゲットアセンブリプロセス（squeeze-i386、squeeze-amd64、natty-i386など）を開始します。 。）。 ビルドが成功するたびに、リポジトリの一時的な構造が更新されます。 すべての目標が正常に収集され、CRONタスク（mc-release-builds.shまたはmc-nightly-builds.sh）のいずれかによってbuildbot.shが呼び出された場合、リポジトリを更新するスクリプトが実行されます。 この時点で、APTサービス情報が更新され、リリースファイルが署名され、サーバーコピーが更新されます。
現在、8つのターゲットの完全なアセンブリサイクルには1時間以上かかります。 将来的には、rpmベースのディストリビューションのターゲットを拡張できるようになるでしょう（私が理解しているように、アップストリームは以前のビルドボットの通常の動作を復元していません）。 追加情報または実行可能なサポートは、 プロジェクトページで入手できます 。