きどたかのブログ

いつか誰かがこのブログからトラブルを解決しますように。

JenkinsとGradleとz/OS

jenkins z/OS USS Gradle
z/OSをJenkinsスレーブにするのは億劫だ。
過去にJNLPでやったことはある。


今回は真っ向勝負でsshでスレーブにすることを試している。


現在一番参考になるのはコレ。


Jenkinsのマスターとスレーブが通信する際に、やはりASCII系のfile.encodingでないと上手く開かない。それは大昔にやったJNLPで気付いている。

このURLでは、USSのFile Tagを使っているが、本当にこれが有効であるのかは自信が持てないものの、Jenkinsジョブに作った「シェルの実行」が動くようなったことは確かではある。


IBM_JAVA_ENABLE_ASCII_FILETAG=ON
この環境変数は、公式には確認できていない。
_BPXK_AUTOCVT=ON
_CEE_RUNOPTS="POSIX(ON),FILETAG(AUTOCVT,AUTOTAG)"
この二つは確認できる。


_BPXK_AUTOCVT=ONは、IBM1047とISO8859-1のコンバージョンしかしないので、file tagを1208(UTF-8)で付けていても意味がねーな。
_BPXK_AUTOCVT=ALLにしやがれと。
だからといって、UTF-8の日本語が1047になるかってんだよ。
だから、FILETAGを使うとしても慎重にならざるをえない、銀の弾丸はなーい。


bin/gradleは、/bin/shでは解釈できない構文を使用しているため、書き換えが必要。とりあえずiconvで1047にして、構文を書き換えて対応している。Javaのオプションのところだ。面倒臭いから、IBM_JAVA_OPTIONS環境変数に突っ込むとかでもいい気がする。
もしくは、自分でbash on z/OSをビルドしてみるとか？  嫌だね。
z/OSで動くbashは、CPC当たりの年間サポートが2000ドルで受けられる。
サポートなしなら、タダでいけるってことか？
ちょっとよく読んでおこう。
サポート料もそこまで高くないし、生産性もいくぶん上がるかもしれないので、わりと検討の価値はかもね。


Jenkinsジョブで、Invoke Gradleを使って、EBCDICに書き換えたgradle(FILETAGはとくに変えてない)を叩きにいくと、
EDC5130I Exec format error になった。
_BPX_SPAWN_SCRIPTを使って回避。
先頭にbashが残ってるせいだったりするのかな？
まー、回避できてるから追求はおいておこう。


gradleのデーモンが動くとやばい。
たしか、sun.io.ConversionBufferFullExceptionがおきる。
正確に解析できてないんだが、新規プロセスでDaemonを立ち上げて、そこへ元のプロセスからGreetingを投げつけたあとに、アウトプットを解析するところで起きてたはず。まあ、文字コードの問題だ。
DaemonOutputConsumerが、デーモンプロセスの標準出力を読み込んでいるようだ。
デーモンプロセスの標準出力は、-Dfile.encodingでは変わらず、-Dconsole.encodingで変わる。
元プロセスがScannerでInputStreamを読み込むと、デフォルトエンコーディングで読んでしまう。
元プロセスは-Dfile.encoding、デーモンプロセスは-Dconsole.encodingということになる。
さて、元プロセスは、ISO8859-1だとかUTF-8で、デーモンプロセスは-Dfile.encoding=UTF-8で-Dconsole.encoding=IBM1047な状況でsun.io.ConversionBufferFullExceptionだったかな。
では、デーモンプロセスの-Dconsole.encodingをUTF-8に変えればどうなるか？
たしか標準出力が化けるので、化けた文字のストリームを受け取ることになり、EncodedStream.EncodedInputクラスあたりで、Unexpected value 240 received. It seems the stream was not encoded correctly.がでたような。。。どっちのどこいじったパターンだったかもう思い出せないよ。


とりあえず、デーモンプロセスの標準出力の箇所は詰んでると思う。
だから、DaemonOutputConsumerなどにパッチをあてる決断をした方がいいと思う。
デーモンプロセスの標準入力のほうはまだ探りきれてない。。。
githubからいろいろ落としてくるのが億劫だ。。。いろんなところでStream使ってるから、どこで文字コードの問題を引き起こすのか追いかけづらい。


しばらくは、デーモンが動かないようにしている。
gradle.prorertiesにデーモン用のjvmargを書かないこと、--daemonを渡さないこと。
bin/gradleに-Dfile.encodingを渡すのはOKだったかな。もしダメなら、IBM_JAVA_OPTIONSで、gradleに気付かれないように密やかに渡す。


gradleの-Dfile.encodingはASCII系でないといけない。そうしないと、依存関係の解決で、リポジトリからjarを取得するのに、ハッシュが合わなくなる。


Jenkinsジョブのコンソールログがちょこちょこ化ける問題は、まだ解析していない。


JarタスクでMANIFEST.MFがNoSuchFileExceptionで、chmod 644失敗しーの、結果としてcopyに失敗する問題にでくわした。
build/tmp/jar/META-INF/MANIFEST.MFにファイルはある。すでに644。
おい、どーした。


とりあえずJarタスクを-xでスキップして、テストを動かしたらば、jacoco-agentのMANIFEST.MFでほぼ同様の事象に出くわした。なんで解凍する必要があるんだよ。


道程は果てしなく長い模様。