2014年10月1日水曜日

Jenkinsのビルド出力結果にjava.nio.file.DirectoryNotEmptyException

概要

Jenkinsのビルドを実行した際にビルドは成功しているのだがビルドの出力結果に以下のような怪しいログが出ていることがわかりました

ユーザーanonymousが実行
ln builds\lastSuccessfulBuild C:\Program Files (x86)\Jenkins\jobs\job_name\lastSuccessful failed
java.nio.file.DirectoryNotEmptyException: C:\Program Files (x86)\Jenkins\jobs\job_name\lastSuccessful
     at sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown Source)
     at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(Unknown Source)
     at java.nio.file.Files.deleteIfExists(Unknown Source)
     at sun.reflect.GeneratedMethodAccessor110.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
     at java.lang.reflect.Method.invoke(Unknown Source)
     at hudson.Util.createSymlinkJava7(Util.java:1194)
     at hudson.Util.createSymlink(Util.java:1112)
     at hudson.model.Run.createSymlink(Run.java:1838)
     at hudson.model.Run.updateSymlinks(Run.java:1819)
     at hudson.model.Run.execute(Run.java:1730)
     at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
     at hudson.model.ResourceController.execute(ResourceController.java:88)
     at hudson.model.Executor.run(Executor.java:234)
ln builds\lastStableBuild C:\Program Files (x86)\Jenkins\jobs\job_name\lastStable failed
java.nio.file.DirectoryNotEmptyException: C:\Program Files (x86)\Jenkins\jobs\job_name\lastStable
     at sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown Source)
     at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(Unknown Source)
     at java.nio.file.Files.deleteIfExists(Unknown Source)
     at sun.reflect.GeneratedMethodAccessor110.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
     at java.lang.reflect.Method.invoke(Unknown Source)
     at hudson.Util.createSymlinkJava7(Util.java:1194)
     at hudson.Util.createSymlink(Util.java:1112)
     at hudson.model.Run.createSymlink(Run.java:1838)
     at hudson.model.Run.updateSymlinks(Run.java:1820)
     at hudson.model.Run.execute(Run.java:1730)
     at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
     at hudson.model.ResourceController.execute(ResourceController.java:88)
     at hudson.model.Executor.run(Executor.java:234)

ビルドは成功しているのにエラーが出ているという気持ち悪い状態になったので対応してみました

環境準備

  • Windows 2008 R2
  • Jenkins 1.5.73

対応方法

Jenkinsの公式で配布されている.exeファイルからインストールするとインストールディレクトリは
C:\Program Files (x86)\Jenkins\
となり
C:\Program Files (x86)\Jenkins\jobs\
がジョブを管理するディレクトリになると思うので上記にインストールされていることを想定して話を進めます

今回のエラーはlastSuccessfulBuildlastStableBuildというディレクトリが空じゃないよと言われて怒られているようです

確かにエクスプローラ等で
C:\Program Files (x86)\Jenkins\jobs\job_name\lastSuccessful
のディレクトリを見ると空ではないようでした
(archiveディレクトリやらbuild.xmlやらchangelog.xmlやらがありました)

なので素直にlastSuccessful配下にあるファイルをすべて削除してからビルドしてみたのですが、同様にエラーが発生しました
なので思い切ってlastSuccessfulのディレクトリごと削除してからビルドしてみたところ、なんとエラーが出なくなりました

エラーが出なくなったあとのディレクトリ構成を見てみると、これまでディレクトリになっていたlastSuccessfulがシンボリックリンクになっていました

どうやらlastSuccessfulは本来シンボリックリンクで管理されるものらしくbuilds/lastSuccessfulというディレクトリに対するシンボリックリンクになっていました

とりあえずこれでエラーは出なくなったのですが、ではなぜlastSuccessfulがシンボリックリンクではなくディレクトリになってしまっていたのでしょうか・・・

記憶しか遡れなかったのですが、自分がJenkinsをインストールした際に前に使っていたジョブの設定をそのままインポートしたくてjobs配下のファイルを事前にバックアップしておきました
そして、普通に.exeファイルからJenkinsをインストール後jobs配下のファイルやディレクトリをごそっとバックアップしておいたものに置き換えました
おそらく、この置き換えの動作を行ったときにシンボリックリンクからディレクトリに変わってしまったのだと思います
バックアップをzip圧縮で取っていたのでzipで圧縮した際にシンボリックリンクでは保存できずにディレクトリに置き換わったのだと思います

うーん、そもそもWindows使ってるほうが悪いとかそういう問題もありますが、公式でもディレクトリをコピーしてねって言ってるみたいだし、、、でもzip圧縮とかするとシンボリックリンクじゃなくなるみたいだし
zip圧縮しないでバックアップしとけってことですかね

0 件のコメント:

コメントを投稿