/var/log/study

つまり雑記

gitリポジトリをCIするのに Jenkins Pipeline もしくは Jenkinsfileが辛いなぁと思った話

背景

  • いくつかでCIをやってみた
    • golangのプロジェクトをgitlab CI で
    • swiftのiosアプリをbitrise.ioで
    • CircleCI で Railsのアプリ
  • システムではなくソースコードをCIしたい
  • 本家?のJenkinsはやってみてなかった
    • GUIでポチポチ形式が割りと嫌
  • そう言えばJenkinsfileがあるらしい
    • 宣言的にCIの内容を書ける
    • チャレンジしてみよう

Jenkinsfileとは

jenkins.io

  • GroovyでCIのjobのステップを宣言するやつ
  • とは言えJenkins上でプログラムだと何でも動かせるので制約がいくつか付いている
    • 制限突破をするための設定があるので余り気にならない可能性はある
  • Jobの実行時にYes/Noをinputできるようにしている

辛さ

ちょっと触って詰まって調べた程度なので間違いはあるかもしれません

  • Jenkinsが想定している前提が広いこと
    • 他のCIならばgitとリポジトリに対するイベントが前提となっていると思う
  • Jenkinsfileが閉じていること
    • webhookでキックすることはできる 
      • Jenkinsfileだけではwebhookのpayloadが拾えない
      • webhookのpayloadを拾うにはJenkinsfile以外の仕組みが必要
    • 環境変数がJenkinsのGUIから設定できない
      • チャットへの通知用にtokenとかは以下を実現したい
      • 厳密にいうと環境変数へのアクセスはできるが、変数はサーバーにログインして設定する必要があるはず
  • いろいろやろうとすると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で良いのかも。」と思った。