2016年3月28日月曜日

[Jenkins] 成果物(画像)を貼り付ける

今回は成果物に保存した画像ファイルをビルドページのトップに貼り付ける方法を紹介します。




なぜ、こんなことが必要かと言うと、
成果物ファイルを確認しようと思った時にリンクを一度クリックする必要があり、これが面倒くささに繋がります。
この一手間をなくすことで、より快適な環境になり、利用者の利点になります。

メリットの話はここまでにして、やり方を紹介します。

Groovy Postbuild Plugin
みんな大好き Groovy Postbuild Plugin !!
今回も Groovy を使用します。
ポイントは2つ、成果物パスの取得とサマリーへの img タグ挿入です。
実際のコードを見ていきましょう。

static createArtifactImageSummary(manager)
{
  def a = manager.build.getArtifacts()
  a.each {
    def path = it.relativePath
    if( path ==~ /.*\.(png|jpeg|jpg|bmp)/ ) {
      manager.listener.logger.println(path)
      manager.createSummary("clipboard.gif").appendText("<img src=\"artifact/$path\"><br />$path", false, false, false, "red")
    }
  }
}
Github

成果物のパスは、manager.build.getArtifacts() で取得した成果物リストを巡回して、relativePath から相対パスが取得できます。画像ファイルであれば manager.createSummary でサマリーを作成。さらに appendText で img タグを挿入しています。

これだけです。
これだけですが、このちょっとしたひと手間で閲覧者の面倒くささが取り除けます。
今回は画像ファイルでしたが、テキストなどの成果物でも応用ができると思います。
ぜひ試してみてください。

以上。


2016年3月23日水曜日

Jenkins でズンドコキヨシ

最近流行(ちょっと出遅れてますが…)のズンドコキヨシを Jenkins でやってみました。
ズンドコキヨシまとめ - Qiita

どうやってやったのか?ですが、ジョブでズンドコキヨシを表現してみました。
まずは結果をご覧ください。(小さいのでクリックしてみてください)

www.oyama-dansen.co.jp

構成
ジョブは以下の4つ。

最初の起点となる「きよしのズンドコ節」ジョブと、「ズン」、「ドコ」、「キヨシ」ジョブの4つのジョブが以下のようにつながっています。

ランダムに下流ジョブを実行
「ズン」と「ドコ」をランダムに実行させるために、
Groovy Postbuild PluginFlexible Publish Plugin を使用しました。



Groovy Postbuild でランダムにビルドステータスを「不安定」か「失敗」に変更しています。
(コードは後述。 Gist にも公開してます。)
Flexible Publish で「不安定」の場合は、「ズン」。「失敗」の場合は、「ドコ」を実行するように設定しています。


ズンドコキヨシ
メインのズンドコ関数ですが、まず判定は Groovy Postbuild で行っています。
判定コード:
import hudson.model.Cause.UpstreamCause
static setNext(manager)
{
  def r = Math.floor( Math.random() * 2 ) as int
  manager.listener.logger.println r
  if( r ) {
    manager.buildUnstable()
  } else {
    manager.buildFailure()
  }
}

static checkZUN(manager, cause, count)
{
  def causes = cause.getUpstreamCauses()
  def name = cause.getUpstreamProject()
  manager.listener.logger.println name
  if( name == "ZUN" ) {
      count += 1
      if( count == 4 ) {
        return true
      }
  } else {
    return false
  }
  cause = null
  causes.each {
    if( it instanceof UpstreamCause ) {
      cause = it
      return
    }
  }
  return checkZUN(manager, cause, count)
}

static check(manager)
{
  def name = manager.build.getProject().getName()
  manager.listener.logger.println name
  if( name == "DOKO" ) {
    def cause = manager.build.getCause(UpstreamCause.class)
    if( checkZUN(manager, cause, 0) ) {
      return true
    }
  }
  setNext(manager)
  return false
}

ズンドコの判定は「ドコ」ジョブで行います。

check(checkZUN) 関数では、UpstreamCause を辿って上流ジョブのジョブ名を取得していきます。
取得したジョブ名を使って、「ズン」、「ズン」「ズン」、「ズン」「ドコ」となったらビルドを「成功」にします。
ならなかった場合は、次のジョブにつなげるためにまたランダムでステータス変更をします。

ズンドコが成立すると「成功」ステータスになるので、あとは「成功」ステータスのときのトリガーを追加すれば完成です。


画像
最後にお遊びで付けた画像ですが、これは createSummary, appendText で img タグを挿入しています。
画像ファイルはワークスペースに配置すれば、ビルドページからワークスペースへの相対パスで参照できます。
具体的にはこんな感じに設定しています。

manager.createSummary("clipboard.gif").appendText("<img src=\"../ws/KIYOSHI.jpg\">
キ・ヨ・シ!!", false, false, false, "red")

来週はこれをもう少しカスタマイズして、成果物の画像ファイルを貼り付ける方法を紹介します。

最後に
今回は Pipeline Plugin (旧Workflow Plugin) を使いませんでした。(自分がほとんど使ってないので)
Jenkinsでビルドのパイプラインを作るぞー!(2016年2月版) - Mitsuyuki.Shiiba
あとはもう少し見た目をよくしたいなと思いましたが、時間がないのでここまでにしました。
誰かこの辺もチャレンジしてくれたらな~(私が大変喜びます)と言って締めたいと思います。では~

2016年3月14日月曜日

[AppVeyor] リモートデスクトップでアクセスしてみた

AppVeyor ではワーカーマシンにリモートデスクトップでログインできます。
Accessing build worker via Remote Desktop (RDP) - Appveyor

iutest の cygwin ビルドのテストが落ちていたのですが、ログだけでは原因がよくわからなかったのでリモートデスクトップでアクセスしてみました。

設定
Accessing build worker via Remote Desktop (RDP) - Appveyor
こちらの説明では、init と on_finish のタイミングで RDP を有効にする方法が説明されています。

ビルド開始直後から有効にする場合は、下記の PS スクリプトを init で実行するように設定をします。
iex ((new-object net.webclient).DownloadString('https://raw.githubusercontent.com/appveyor/ci/master/scripts/enable-rdp.ps1'))


ビルド終了後に有効にする場合は、下記の PS スクリプトを on_finish で実行するように設定をします。
$blockRdp = $true; iex ((new-object net.webclient).DownloadString('https://raw.githubusercontent.com/appveyor/ci/master/scripts/enable-rdp.ps1'))

いずれの場合も時間制限があり、60分までとなっています。

ログインする
設定ができたら、ビルドを実行します。すると、
以下のようにコンソールログがでるので、そのアドレスとユーザー名、パスワードでリモートデスクトップ接続します。

init:

on_finish:



はい。できました。
これだけです。とっても簡単ですね。

日本語キーボード
リモートデスクトップでログインするとキーボードが英字配列として認識されて、やり辛かったです。
対処方法を色々試してみましたが、結果としては上手くいかず。
誰か教えて下さい~><

まとめ
AppVeyor は至れり尽くせり。
(テキトーまとめごめんなさい)

2016年3月7日月曜日

[Jenkins] NodeLabel Parameter Plugin + Groovy Label Assignment plugin でノードをパラメータにしつつ別ノードで実行する

NodeLabel Parameter Plugin は「ブログズミ: [Jenkins] ノードやラベルを指定して実行する」で紹介をしました。
Groovy Label Assignment plugin は「ブログズミ: [Jenkins] 同じノードで繰り返し実行されないようにする方法」で紹介をしました。

この2つを組み合わせることで、ノードをパラメータとしつつ、実行ノードは別にすることにできます。

どういうことかと言うと、
「NodeLabel Parameter Plugin」はノードをパラメータにできます。
右のようなに、ノードがリストで選べるので非常に便利です。

そして、このパラメータで選ばれたノードは、実行ノードとして利用されます。通常利用の範囲ではこの動作で問題ないと思うのですが、たまーに実行ノードを別にしたいことがあります。
(私の場合、メンテナンス系のジョブで必要になりました。)


そこで、「Groovy Label Assignment plugin」の出番です。
設定
ジョブの設定で「Groovy スクリプトで実行するノードを制限」を以下のようにします。
def label = currentJob.assignedLabel
return label
「実行するノードを制限」に設定を返すようにしているだけです。
これで「NodeLabel Parameter Plugin」に上書きされるラベル式を、「実行するノードを制限」の設定に戻すことができます。



実行
実際に実行するとこんな感じです。

slave3 をパラメータとして実行。


master ラベルが割当られて、master で実行されます。

まとめ
ノード選択でも Groovy の力を借りると幅が広がります。
Groovy Label Assignment plugin をぜひお試しください。