openSUSE:Build Service での共同作業
概要
Open Build Service には様々な共同作業のための方法が用意されています。もっとも簡単な方法としては、パッケージやプロジェクトに対して書き込み権限を付与する方法がありますが、これは小規模なチームでは最も素早く動くことができて便利な方法です。
しかしながら、上記の方法では下記のような理由から、問題となる場合があります:
- 登録されていないユーザは書き込み権限がないので、変更点を送信することができない。
- 多数のユーザに対して書き込み権限を与えてしまうと、プロジェクトの信頼性が低くなってしまう。
- 人によっては、プロジェクト内に取り込む前に他者のレビュー (確認) を必要とする場合がある。
- 巨大なプロジェクトで連続して変更が発生すると、プロジェクト内のパッケージの構築が終わらないうちに次の変更が行なわれてしまうことがある。このパッケージが、他のパッケージの基礎となるものであったりすると、他のパッケージの構築をずっと止めてしまう原因になってしまう。
このような理由から、 Open Build Service では共同作業を行なうためのもう 1 つの方法を用意しています。それは、ブランチ (分岐) と呼ばれる仕組みで、変更点を作業用に別途用意した場所でテストしてから、本来のプロジェクトに反映させる方法です。
KDE や GNOME, Apache, YaST などの巨大なプロジェクトでは、さらにもう 1 つの確認を必要とする場合があります。それはステージングと呼ばれる方法で、メインのプロジェクトに取り込む前にもう 1 つの段階 (プロジェクト) を用意する方法です。これは openSUSE:Factory プロジェクトで用いられている方法で、このプロジェクトでは各パッケージに対して開発用のプロジェクトを指定します。 Open Build Service では、まず各ユーザからの提供物を開発用のプロジェクトに送信してもらいます。開発用のプロジェクトの所有者は、提供物がまとまった段階でそれらをまとめて openSUSE:Factory に送信します。処理の流れは、 これらのスライド にまとめられています。
コマンドラインの使用例
Open Build Service で使用するコマンドライン (CLI) のクライアントは、 "osc" と呼ばれています。 osc の最新版は、 openSUSE:Tools プロジェクト内に用意されています。
|
警告!
|
このページは osc のバージョン 0.119 以降の UI を説明しています。それ以前のバージョンの場合、コマンドが若干異なっていることにご注意ください。 |
他のユーザのパッケージに対して変更点を送信するには
たとえば openSUSE:Factory プロジェクト内の initviocons というパッケージに対して作業を行ない、作業が終わったら結果を openSUSE:Factory プロジェクトに送信したい場合を考えます。
下記に手順を示します。
ブランチパッケージの作成
まずは自分用のプロジェクト (home プロジェクト) 内に、ブランチ (分岐) プロジェクトを作成します。
# osc branch <分岐元プロジェクト> <分岐元パッケージ> osc branch openSUSE:Factory initviocons
このコマンドを実行すると、 home:(あなたのユーザ名):branches という新しい個人用 'ブランチプロジェクト' を作成 (それまで存在していなかった場合のみ) します。このブランチプロジェクト内には、ブランチ元のプロジェクトと同じ構築手順が設定されるほか、ブランチ内にソースリンクとしてパッケージが作成されます。
多くのパッケージには '開発 (Devel) プロジェクト' が定義されています。開発プロジェクトが定義されているパッケージであれば、分岐元のプロジェクトではなく、開発プロジェクトに対してリンクを作成します。これは 'osc branch' の出力で確認することができます:
# openSUSE:Factory からパッケージをブランチするが、実際には異なるプロジェクトで開発されている場合 osc branch openSUSE:Factory glib2
上記のように実行すると、 home:(ユーザ名):branches:GNOME:UNSTABLE プロジェクト内に glib2 パッケージが作成されます。
This ensures that your changes follow the existing flow of changes into the package's real home.
自分のリポジトリ内での変更作業
ブランチパッケージを作成したら、そこから作業を開始します。下記のコマンドを実行します:
osc checkout home:(ユーザ名):branches:openSUSE:Factory/initviocons cd home:(ユーザ名):branches:openSUSE:Factory/initviocons
上記を実行すると、ローカルのファイルシステム内にパッケージをチェックアウト (取り出す) することができます。リポジトリ内ではリンクだったものも 展開 されます。パッケージをブランチする際には、全体をコピーするのではなく分岐元へのリンクが作成されるだけです。このリンクの仕組みにより、ブランチパッケージは分岐元に同期して更新されるようになっています。ブランチ内で作業を行なうには、リンクではなくパッケージに対する実際のソースコードが必要ですが、チェックアウトの処理でリンクを 展開 し、実際の内容に置き換えるようになっています。そのため、チェックアウト時には元々のソースコードやファイルなどとともに、変更点も受け取ることになります。
# あとは作業を行うだけです vi ... osc status vi ... osc vc
変更の作業は新しい機能を追加するものでも、何らかの問題を修正するものでも、改善するものでもかまいません。
# ローカルでの構築 osc build
ローカルでの構築作業は、開発にかかる時間を削減するためのものです。わざわざ作業途中のファイルを Open Build Service に送信して、構築が完了 (もしくは失敗) するのを待つ必要はないからです。
構築が完了したら、あとは Open Build Service に変更点を送信します:
# 変更点の送信 (コミット) osc commit -m "changed this and that"
これで変更点が送信され、構築がスケジュールされます。
ソースコードをチェックアウトした場合であっても、ベースとなるパッケージに対するパッチ (差分) を作る必要はありません。 Open Build Service は、ブランチパッケージとブランチ元パッケージを比較して、自動的に必要な差分を生成します。
しばらく待ったあと、下記を実行することで結果を取得することができます:
# check whether it builds osc results
あとは必要に応じて、変更したことによる動作の差異を確認したりすることができます。また、他の誰かと変更点について議論したり、他の開発者が何をやっているのかを確認したりすることもできます:
# あなたのバージョンと openSUSE:Factory のバージョンとの差分の確認 osc rdiff home:(ユーザ名):branches:openSUSE:Factory initviocons
構築結果のデバッグ
osc build を実行すると、 build ディレクトリ内に各種のファイルが記録されます。これらは問題を分析する際に必要な情報です。 build ディレクトリは、 osc build の最後のほうに下記のように出力されます:
The buildroot was: /var/tmp/build-root
表示されたディレクトリ内には、下記のようなファイルがあります:
| 名前 | 意味 |
|---|---|
| .build.log | 構築結果とエラーのログ |
| .build.command | 実際の構築処理で実行したコマンド |
| .build.packages | オブジェクトファイルの場所 |
構築処理が失敗した場合は、 build ディレクトリ の中で作業を行ないたくなってしまうものですが、これはあまりお勧めできません。なぜなら、 osc build コマンドは build ディレクトリ内にあるすべてのファイルを削除 (rm -rf) し、何もない状態から構築を開始するためです。ただ、このような方法では、特に巨大なプロジェクトなどで構築に時間がかかることから、あまり現実的ではない場合があります。この問題を回避するには、 .build.command ファイルをお読みください。通常であれば、下記のような行が記録されているはずです:
rpmbuild -ba package.spec
上記のコマンドは、以前に構築した内容を破棄して最初からやり直す処理です。これが時間のかかる原因になっていますので、下記のようなコマンドで構築を再開してください:
rpmbuild -bc --short-circuit package.spec #コンパイル rpmbuild -bi --short-circuit package.spec #インストール
これらのオプションは、 Fedora RPM ガイド に記されています。
変更結果のマージ (結合)
|
|
警告!
|
この機能は openSUSE:11.0 や Fedora:9 、もしくは *:Update のような凍結 (フリーズ) 済みプロジェクトに対しては実行できません。これらのプロジェクトに対して変更結果を送信するには、メンテナンス要求 (maintenancerequest) と呼ばれる作業が必要になります。 |
変更作業が完了し、問題なく構築できて動作することを確認し、提供元のプロジェクトのメンテナンス担当者に対して送信できることを確信したら、あとは送信処理を行なうだけです (もちろん -m 以下のコメントには、英語で記載してください):
osc submitrequest -m 'version update to 3.3'
上記を実行すると、ローカルのディレクトリ内にあるパッケージ内の変更を、ブランチ元のプロジェクトに送信します。
チェックアウトしたパッケージでない場合 (たとえばコピーしただけのパッケージなど) は、下記のように実行してください:
osc submitrequest home:(ユーザ名):branches:openSUSE:Factory initviocons openSUSE:Factory -m 'version update to 3.3'
上記を実行することにより、 Factory に対して変更を送信することができます。送信先のプロジェクトのメンテナンス担当者は、変更した内容をすぐに確認することができます。その変更に問題がなければ、担当者は差分を取り込むことになります。何か問題があって受け入れられない場合は、その旨 (やるべきことなど) の回答が届きます。
どのようにして変更点を取り込むのか
プロジェクト (たとえば openSUSE:Factory) のメンテナンス担当者は、さまざまな貢献物 (submitrequest などで送信されたもの) を一覧で確認することができます。たとえば下記のようになります:
% osc request list openSUSE:Factory 37 new home:poeml/initviocons -> openSUSE:Factory/initviocons 'version update to 3.3'
メンテナンス担当者は、現在のパッケージのソースコードとの間で差分を確認し、受け入れるかどうかを判断して、受け入れられない場合は理由を説明します。
% osc request show -d 37
Request to submit (id 37):
home:poeml/initviocons -> openSUSE:Factory/initviocons
Source revision MD5:
f839321325a0b5582def283c3520bf13
Message:
'version update to 3.3'
State: new 2008-03-20T19:57:02 poeml
changes files:
--------------
--- initviocons.changes
--- initviocons.changes
@@ -20 +20 @@
- which sends a characteristic primary da
+ which sends a characteristic primary DA
[...]
受け入れる場合は、下記のようにして送信されたものを受け入れます:
osc request accept 37
拒否する場合は、理由を説明します (英語で) :
osc request decline -m "changelog missing, but required by policy" 37
Web インターフェイスの使用例
本章では、 Web インターフェイスを介してソースコードを変更する方法を示しています。 openSUSE Build Service にアクセスするには、 http://build.opensuse.org を開いてください。
Web UI は、エラーやパッケージの説明など、概要をつかんで簡単な変更を行なうのに適した仕組みです。より複雑な変更を行ないたい場合や、マージ (結合) 時の問題を解決したりしたいような場合には、 CLI のほうがお勧めです。
他のユーザのパッケージに対して変更点を送信するには
たとえば openSUSE:Factory プロジェクト内の initviocons というパッケージに対して作業を行ない、作業が終わったら結果を openSUSE:Factory プロジェクトに送信したい場合を考えます。
下記に手順を示します。
ブランチパッケージの作成
上記のプロジェクトには直接書き込むための権限をお持ちでないはずですし、すべてのユーザに反映する前にまずローカルの環境でテストをすべきでもありますので、まずはブランチ (分岐) パッケージを作成します。ブランチパッケージは一般的に元のパッケージのコピーです。
分岐したパッケージは通常、分岐元のパッケージで行なわれた変更を自動的に結合します。
まずは openSUSE:Factory プロジェクトのページ内にある パッケージリスト から、必要なパッケージを探します。
ブランチプロジェクトの作成
まずは自分用のプロジェクト (home プロジェクト) 内に、ブランチ (分岐) パッケージ (とプロジェクト) を作成します。 "Actions" メニューから "Branch package" を選択します。
すると、サーバは home:(ユーザ名):branches 内に新しいプロジェクト (ブランチプロジェクト) を作成します。このブランチプロジェクト内には、ブランチ元のプロジェクトと同じ構築手順が設定されるほか、ブランチ内にソースリンクとしてパッケージが作成されます。
多くのパッケージには '開発 (Devel) プロジェクト' が定義されています。開発プロジェクトが定義されているパッケージであれば、分岐元のプロジェクトではなく、開発プロジェクトに対してリンクを作成します。
自分のリポジトリ内での変更作業
"source files" のタブを選んで、ソースコードに対して必要な変更を実施します。変更後は、構築処理が終わるまでしばらく待つ必要があります。
構築が完了したら、パッケージをダウンロードして、変更点が正しく反映されているかどうかを確認します。
変更結果のマージ (結合)
|
|
警告!
|
この機能は openSUSE:11.0 や Fedora:9 、もしくは *:Update のような凍結 (フリーズ) 済みプロジェクトに対しては実行できません。これらのプロジェクトに対して変更結果を送信するには、メンテナンス要求 (maintenancerequest) と呼ばれる作業が必要になります。 |
変更作業が完了し、問題なく構築できて動作することを確認し、提供元のプロジェクトのメンテナンス担当者に対して送信できることを確信したら、あとは送信処理を行なうだけです。
これを行なうには、 "Actions" メニュー内にある submit request を選択するか、もしくは "Source Files" ページにある "show diff and submit these changes back" のリンクを使用します。
上記を実行すると、宛先の作者に対して要求が作成され、変更点のレビューと受け入れ (承認) を求めるようになります。マージが完了すると、ブランチパッケージは削除されます (あえて指定した場合を除きます) 。
openSUSE:Factory プロジェクトでの特殊な処理
openSUSE:Factory 内にあるパッケージには "開発 (Devel) プロジェクト" が定義されています。これらの開発プロジェクトは、パッケージそのものの開発を取り扱うところ (osc meta pkg openSUSE:Factory <パッケージ名> | grep devel コマンドを実行することで、開発プロジェクトを知ることができます) で、たとえば下記のように実行すると、 osc branch openSUSE:Factory <パッケージ名> その開発プロジェクトからファイル類をコピーすることになります。
openSUSE:Factory に対して submitrequest を実施 (注意: 開発プロジェクト内で submitrequest を受け入れたからと言って、 Factory に自動的に submitrequest されるわけではありません) するには、開発プロジェクト側のメンテナンス担当者が、下記のような処理を実行する必要があります:
osc sr -m "- updated package, thanks to foo bar" <開発プロジェクト名> <パッケージ名> openSUSE:Factory
このようなことから、下記 2 つのタイプのシナリオが考えられます:
ブランチまたは非公式 Devel (開発) プロジェクトのメンテナンス担当者の作業
- osc branch openSUSE:Factory <パッケージ名>
- osc submitrequest (開発プロジェクトに対して submitrequest を送信する)
- 開発プロジェクトのメンテナンス担当者は、 osc sr accept <id> で受け入れを行なう
- 開発プロジェクトのメンテナンス担当者は、 Factory に対して submitrequest を行なう
- Autobuild が変更点を受け入れる
公式 Devel (開発) プロジェクトのメンテナンス担当者の作業
- 開発プロジェクトのメンテナンス担当者は、 Factory に対して新しい submitrequest を行なう
- Autobuild (openSUSE:Factory チーム) が変更点を受け入れる
osc request list <devel:project>