Hudson と Jenkins を両方使ってみて分かった両者の違い

かねてより書いているとおり、当工房では Hudson と Jenkins をともに運用しているわけで、これまでに分かった両者の違いをまとめてみます。

  1. Jenkins の方がコミュニティに活気があり、プラグインも多い。
  2. Hudson は同梱されているプラグインが少なく、最初の起動時にダウンロードするようになっている。
  3. Hudson では Jenkins にもある Maven プロジェクトがレガシー扱いになっていて、自由形式プロジェクトで扱えるように変更されている。
  4. Hudson ではマスター ノードの構成が Jenkins のようには独立していない。
  5. Hudson にはカスケーディング ジョブがあり、ジョブの継承やテンプレート的な利用が標準機能だけで可能になっている。
  6. Jenkins は ${user.home}/.jenkins${user.home}/.hudson がどちらもあると後者を優先して利用する。システム プロパティで JENKINS_HOME を設定しない限り、同一アカウントでは共存できない。

最後のは違いではないですが、どちらも使ってみたい方には参考になるのではないかと思います。

 

Hudson のカスケーディング ジョブを使ってみました。

Hudson のバージョン 2.2.0 以降 (執筆時の最新はバージョン 3.2.1) で利用可能になったカスケーディング ジョブ (英語では Cascading Job ですが日本語の訳語が未確定のため暫定的にカタカナで表記します) を初めて使ってみました。これは基本的にジョブ構成の継承機能で、これを使うことであるジョブの構成を一部だけ変更した派生ジョブを簡単に作れてしまいます。

使い道としては、SCM の別ブランチをビルドするジョブを作成するというのが挙げられていますが、他にも活用はできそうですね。これだけのために Hudson を使うというのもありかもしれません。

最近のオープンソース活動 (Hudson 編)

Hudson のプラグイン チームに参加することになったというのは既報のとおりですが、最近のオープンソース関係の活動を一つ紹介しておきます。

今回紹介するのは、HudsonSSH スレーブを起動したときに新規ディレクトリのアクセス許可が変な設定になる不具合の修正です。

POSIX のアクセス許可は、本来 8 進数で表記するべきところを 10 進数で書いていたため、結果的におかしくなっていたというだけなのですが、バージョン 3.2.1 まで出しておいて今まで誰も気が付かなかったのかと言うような話で、Jenkins と分かれてしまった Hudson 側の人材不足はかなり深刻みたいですね。

Hudson と Jenkins の共存

Jenkins を稼働させているアプリケーション サーバーに比較のため Hudson を追加インストールしたら、JenkinsHudson${user.home}/.hudson を見に行っておかしくなっていた模様です。普通は自分のディレクトリ (${user.home}/.jenkins) が既にあれば、そっちを先に見に行くものだと思うのですが、どこか間違っている気がします。

結局、アプリケーション サーバー側で JENKINS_HOME を正しいディレクトリに設定して分離には成功しましたが、この挙動は腑に落ちません。