gitリポジトリをCIするのに Jenkins Pipeline もしくは Jenkinsfileが辛いなぁと思った話
背景
- いくつかでCIをやってみた
- システムではなくソースコードをCIしたい
- 本家?のJenkinsはやってみてなかった
- GUIでポチポチ形式が割りと嫌
- そう言えばJenkinsfileがあるらしい
- 宣言的にCIの内容を書ける
- チャレンジしてみよう
Jenkinsfileとは
- GroovyでCIのjobのステップを宣言するやつ
- とは言えJenkins上でプログラムだと何でも動かせるので制約がいくつか付いている
- 制限突破をするための設定があるので余り気にならない可能性はある
- Jobの実行時にYes/Noをinputできるようにしている
辛さ
ちょっと触って詰まって調べた程度なので間違いはあるかもしれません
- Jenkinsが想定している前提が広いこと
- 他のCIならばgitとリポジトリに対するイベントが前提となっていると思う
- Jenkinsfileが閉じていること
- いろいろやろうとするとJenkinsfile外との連携を考える必要が出てくる
- Jenkinsfileの良さを殺している
雑記
冒頭で述べたように個人的にはGUIでしか設定できないのは嫌なのだが、「Jobの内部はJenkinsfile, 外部とのやり取りはGUIで設定」という現状は結局GUIでの設定に依存していてはっきり言って不便。
ソースコードをCIするだけならば、GitlabCIもしくはSaaSのCIが圧倒的に便利。前提として考えているワークフローがJenkinsとそれ以外では違いすぎる。
JenkinsはOSSだから文句を垂らすならコントリビュートする努力をしたほうが良いのだろうけど、便利な代替があるので、不便なJenkinsfileを改善する努力もするつもりが無い。
自分の観測範囲だとJenkinsはスクリプトにGUIを提供するためのラッパーツールっぽくて、CIツールとしてはあまり使われていない。多分だけど自分の観測範囲外でも同じような使われかたをしているのでは?と思えるJenkinsfileの機能だと思った(Job実行時のyes/noとか)。ただ僕にとってはスクリプトをラップしたGUIとか何も有り難みが無い。結局設定されているスクリプトを見るし、直接たたいてオプションとか調べるし。調べた後はJenkinsが無駄なGUI層として残ることになる。
が、スクリプトをラップしたGUIは、スクリプトを読めない人でも安心して実行することができる利点?があるので、Jenkinsはそっちの方で生き残るのかな?
ココまで書いて、「自分が主体的に使うシーンを想定すると割りと辛い気持ちになり、他人のためにスクリプトのラッパーを用意してあげるだけならばJenkinsで良いのかも。」と思った。