ソースコード

Jenkins の groovy pipeline で書いたもの。

                    approvalResult = input(
                        id: "myInput",
                        message: "承認しますか？",
                        parameters: [
                            string( name: 'comment', defaultValue: '承認します')  
                        ],
                        submitterParameter : "approver" 
                    )
                    wrap([$class: 'BuildUser']) {
                        if( approvalResult.approver.equals(BUILD_USER_ID) ) {
                            error "承認者と作業者が同じ人です！！";
                        } else {
                            echo approvalResult.comment;
                        }
                    }

ダブルチェック

一人で何でもできる状況でお仕事とか管理をしたりするとスムーズに事が進んで大変に楽なのだが「それやっちゃまずくね？」を止める人がいない。お仕事や管理の内容によっては不正やよろしくない判断をだれも止めることができない、ということになる。

それを防ぐために不正やよろしくない判断に基づく可能性のある作業に対しては作業者じゃない誰かが確認するプロセスを踏んだ方がよい、とされる。上述のソースコードはこの確認するプロセスを実現している。

解説

Jenkins の groovy pipeline の Input Step と BuildUser を使っている。

input を使うとビルドの最中にユーザの入力を受け付けることが可能となる。これを使ってビルドの途中で「承認しますか？」を確認する。承認時にはしばしば承認の根拠になる資料を添付したくなるのでそういう URL を添付しやすいようにコメントを書き込めるようにしてある。他にも様々な値を与えることが可能である。しかし、最も重要なのは submitterParameter だろう。これに指定した値を key とする value に承認者のユーザ ID が代入される。上述の例だと approvalResult.approver に承認者のユーザ ID が格納される。

しかし、この承認が作業者自身によるものだったらダブルチェックになっていない。別人が確認していることを確認するために作業者のユーザ ID が格納される BUILD_USER_ID と approvalResult.approver を比較し、双方が異なる値を持つことを確認している。

承認者を絞る

input の submitter パラメータを設定することでそもそも input に入力できる人を制限できる。これを用いれば BuildUser のチェックを省略したり、より高度な確認プロセスを作れるかもしれない。ただし、承認できる人の全リストのメンテナンスをしないといけなくなるので、若干面倒。そこのメンテナンス方法を考えていないと徐々に面倒になってくるはず。