jenkinsのプラグインをsubversionからmercurialに変更するとエラーになる

[shin ohira]

いつもお世話になっております。おおひらです。

henkinsのプラグインをsubversionからmercurialに変更するとそれまで正常に通っていたテストでエラーが発生するという現象がありました。

先日書き込んだ、バージョン番号のズレなど疑っていたのですが結局番号が違っても中身は同じで

問題の発生箇所はプラグインの動作がsvnとhgでは違うことでした。

ビルドの成果物がリポジトリに存在した場合の動作が違うのです、

subversionの場合には、ビルドの成果物がリポジトリに存在してもビルドしなおされて最新のものになるのですが、mercurialのプラグインでは、成果物がリポジトリに存在する場合にはビルドしなおさないで、リポジトリから取り出したバイナリでテストしていたのです。

動作としては、mercurialの方が筋が通っているように思います。jenkinsのプラグインにまで一貫したポリシーが感じられます。

似たような事例が無いかとぐぐってみると、空のディレクトリがなくなって動作が変わると質問している人がいました。回答は、それはリポジトリに入れて管理すべきものではないのではないか？というものでした。

hg convert で　svn の空のリポジトリをコンバートできないのも、空のディレクトリと同じような扱いなのでしょうか。入れるべきではないとの判断なのかな。個人的には空のリポジトリから空のリポジトリにコンバートできたほうが良いのではないかとおもいます。空のディレクトリ入れるのとは少し違うような気がするんです。

[Katsunori Fujiwara]

藤原です。

Jenkins (+ mercurial 連携) に関しては、私はあまり詳しくないので、
とりあえず空ディレクトリ絡みの話にのみ言及しておきます (^ ^ ;;;)


2014年4月18日 20:24 shin ohira <shin....@gmail.com>:

> henkinsのプラグインをsubversionからmercurialに変更するとそれまで
> 正常に通っていたテストでエラーが発生するという現象がありました。
>
> 先日書き込んだ、バージョン番号のズレなど疑っていたのですが結局番
> 号が違っても中身は同じで問題の発生箇所はプラグインの動作がsvnと
> hgでは違うことでした。
>
> ビルドの成果物がリポジトリに存在した場合の動作が違うのです、
> subversionの場合には、ビルドの成果物がリポジトリに存在してもビル
> ドしなおされて最新のものになるのですが、mercurialのプラグインで
> は、成果物がリポジトリに存在する場合にはビルドしなおさないで、リ
> ポジトリから取り出したバイナリでテストしていたのです。
>
> 動作としては、mercurialの方が筋が通っているように思います。
> jenkinsのプラグインにまで一貫したポリシーが感じられます。
>
> 似たような事例が無いかとぐぐってみると、空のディレクトリがなくなっ
> て動作が変わると質問している人がいました。回答は、それはリポジト
> リに入れて管理すべきものではないのではないか？というものでした。

Mercurial では:

(1) ファイルのみを管理対象としている

(2) update 時に、管理対象ファイル削除の結果、空になったディレク
トリも一緒に削除する

という仕様になってるため、空のディレクトリを維持したい場合は、何ら
かのダミーファイルを保持することが推奨されています。

UNIX 系環境では、ls コマンド等が "." で始まるファイルを隠してくれ
るので、".keep" や ".placeholder" 的なファイルを置くことになります。

> hg convert で　svn の空のリポジトリをコンバートできないのも、空
> のディレクトリと同じような扱いなのでしょうか。入れるべきではない
> との判断なのかな。個人的には空のリポジトリから空のリポジトリにコ
> ンバートできたほうが良いのではないかとおもいます。空のディレクト
> リ入れるのとは少し違うような気がするんです。

空の svn からの変換は、「リビジョン 1 の取得失敗による中断」という
体裁になっていますので、変換先リポジトリが "hg convert" によって新
規作成されたものであれば、そのリポジトリは破棄されます。

挙動的には、"hg clone" が失敗した場合に、"hg clone" によって新規に
作成された「clone 先リポジトリ」を残しておかないのと一緒ですから、
私個人としては、それほど違和感は無いですね。

まぁ、「svn 側のリビジョン総数を確認した上で、履歴情報を取りに行け
よ（＝ エラー終了させるなよ）」な気もしますけど、その辺は svn 連携
用の (外部提供) ライブラリが、リビジョン総数確認用の API 等を提供
してくれていないと話にならないので、実現性の有無に関しては何とも言
えませんねぇ (どなたか svn binding ライブラリ周りに詳しい方いらっ
しゃいます？)


変換結果の成否や変換元の履歴量に関わらず、変換先の hg リポジトリの
存在を保証したいのであれば:

1. "hg init hg-dst" で変換先の空リポジトリを作成
2. "hg convert svn-src hg-dst" で変換

という手順での変換がよいのではないでしょうか？

この場合、変換自体に失敗しても、事前に作成された hg-dst は
破棄されません。"hg pull" が失敗しても、pull 先＝ローカルの
リポジトリが破棄されないのと一緒ですね。

--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)

[shin ohira]

おおひらです。

jenkins hg pluginと　svn pluginの仕様の違いということで、現在は問題は解決しましたが、

状況説明など説明不足な点がありましたので、追加で書いておきます。

subversion+jenkinsで動作していた時と、subversion+mercurial+jenkinsで動作しているときの動作の流れは以下のようになります。

subversion+jenkinsの場合(エラーなし)

[svnリポジトリ] -> jenkins svn plugin -> [jenkins workspace]

subversion+mercurial+jenkinsの場合(エラー発生)

[svnリポジトリ] -> hg convert -> [hgリポジトリ] -> jenkins hg plugin -> [jenkins workspace]

説明

svnのバージョンとhgのバージョンが同じものの場合、バージョン番号が1ずれる(仕様ということを知らなかった)

jenkins hg plugin のログが何故かtipではなく一つ前のものを　hg log している(なんでだろ～)

ビルドの成果物がリポジトリに入っている場合にhg plugin はビルドしないでリポジトリからのものをそのまま使う(ｓｖｎは上書き)

=== svn の最新バージョン番号

api - Revision 155: /

=== hg の最新バージョン番号

changeset 154:6bbd6d2f5d84 tip

【変更】

ソース整理

=== hg の一つ前のバージョン番号

changeset 153:2a68c5559163

[変更]テスト3。ソース修正

=== hg plugin の最新ログ (これが一番なぞです,workspaceの中はchangeset 154:6bbd6d2f5d84 tipなのにログはなぜか一つ前のを表示してます)

Started by an SCM change

Building in workspace /var/lib/jenkins/jobs/API_Test/workspace

[workspace] $ hg showconfig paths.default

[workspace] $ hg pull --rev default

pulling from /home/estore/repos/api-hg

no changes found

[workspace] $ hg update --clean --rev default

5 files updated, 0 files merged, 0 files removed, 0 files unresolved

[workspace] $ hg log --rev . --template {node}

[workspace] $ hg log --rev . --template {rev}

[workspace] $ hg log --rev 2a68c55591639480fc6ef5531d45f3780c542d6a

changeset:   153:2a68c5559163

user:        li

date:        Mon Apr 21 03:25:37 2014 +0000

summary:     [変更]テスト3。ソース修正

上のような状況です。hgだと古いバージョンが使われていると勘違いしてしまいました^_^;;;;;;;

（ビルドされたないので、動作的にも古いものだったし)

2014年4月18日金曜日 20時24分37秒 UTC+9 shin ohira: