カテゴリー: Hudson & Jenkins

Hudson と Mercurial を利用した Maven 成果物のリリース管理

/ Kaz Nishimura / コメントする

たまには何か書かないと PV が増えないので、今回は Hudson と Mercurial を利用した Maven 成果物 (artifact) のリリース管理について書いてみたいと思います。

ご存じの方もいるかと思いますが、私は OSSRH を利用して Maven Central Respository に Java 系成果物を公開しています。一例としては Google Login Plugin for Hudson とかですね。

ところで、Maven にはバージョンの末尾に -SNAPSHOT が付くと、リリース前のスナップショットとして扱われるという慣例があります。例えばバージョン X.Y-SNAPSHOT はバージョン X.Y より前のスナップショットという意味になり、Maven のリポジトリーでも別枠となります。

さてここまでを前置きとして、今回紹介するのは Hudson と Mercurial を利用して、成果物のリリースを半自動化してしまう手法です。

Hudson の使い方については別途調べてもらうとして、Hudson を使うことで Maven 成果物のデプロイ (deploy) までは自動化可能です。スナップショットの段階なら Hudson が新しいリビジョンを見つけるたびに自動デプロイしても何ら問題はありませんが、正式のリリースとなるとそうも言っていられません。

一応 OSSRH にステージング機能があるので、デプロイしてもいきなりリリースされることはないのですが、リリースしないものは破棄しなければなりませんので、リリース バージョンの自動デプロイは極力減らしたいところです。

そこで活用するのが Mercurial のブックマークです。例えばブックマーク release-candidate をリリース用のブランチに作成して、Hudson ではこのブックマークを追跡して自動デプロイするようにジョブを作っておきます。こうすると release-candidate の移動に伴ってリリース候補が OSSRH のステージング領域に自動デプロイされることになりますので、リリース OK となったら最後のリリース候補をリリースして残りを破棄すればリリース完了という流れです。

注意点としては、一旦リリースしたら次のリリースまでブックマークを移動しない (つまり自動デプロイしない) ようにすることでしょうか。Git でもブランチの移動を工夫すれば同様のことは可能だと思いますので、ぜひ試してみてください。

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

/ Kaz Nishimura / コメントする

かねてより書いているとおり、当工房では 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 のカスケーディング ジョブを使ってみました。

/ Kaz Nishimura / コメントする

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

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

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

/ Kaz Nishimura / コメントする

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

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

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

Hudson と Jenkins の共存

/ Kaz Nishimura / コメントする

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

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

Jenkins 用 RAD Studio Plugin

/ Kaz Nishimura / コメントする

過去記事を調べてみたらブログには書いてなかったことに気づいたので、改めて RAD Studio Plugin を紹介しておきます。

このプラグインの機能は、RAD Studio (Delphi もしくは C++Builder) のプロジェクトを簡単にビルドできるようにするだけです。必要な環境変数の設定は RAD Studio コマンド プロンプト用のバッチファイルから読み取るので、RAD Studio 各バージョンのインストール先をそれぞれ設定しておけば、ビルドに利用するバージョンを選択して、プロジェクトファイルと MSBuild のコマンド スイッチを指定するだけで、ビルドすることができます。もうバッチ ファイルで細工する必要ありません。

もし役に立つと感じたら、フィードバックをいただけるとありがたいです。

Jenkins 用 Tool Labels Plugin

/ Kaz Nishimura / コメントする

先日の RAD Studio Plugin に続き、調子に乗って Tool Labels Plugin を公開いたしました。

このプラグインの機能は、インストール済みツールによりノードに動的にラベルを追加するというものです。ツールのインストール有無によりビルドを実行するノードを限定するのが目的で製作しました。

実を言えば、RAD Studio Plugin の新機能として企画していたのですが、他のツールにも使えることに気づいて、急遽 独立したプラグインに仕立てたものなのですけどね。例えば、RAD Studio XE7 に bds15.0 というラベルを付けておくと、インストール済みノードに動的にこのラベルが付くので、ビルドを実行するノードを限定するのに使えるようになる訳です。

便利だと感じたらフィードバックをいただけるとありがたいです。

Jenkins 復旧

/ Kaz Nishimura / コメントする

GlassFish アップデートで障害発生から止まっていた Alfa.linuxfront.com の Jenkins がようやく復旧しました。

何が問題を起こしていたのかを簡潔に書けば、GlassFish 4.1 のクラスター インスタンスに配置していたために Jenkins が初期化に失敗していたということでした。単一のスタンドアローン インスタンスに配置替えをしたことにより初期化に失敗することもなくなり、ひとまず平常運転に戻れそうです。

不思議なのは、前バージョンの GlassFish 4.0 ではクラスター インスタンスでも動いてたってことなんですよね。4.1 で動作が変わったのでしょうか。