다양한 jenkins plugin이 있고 다양한 방법이 있기 때문에 혼란스럽고 약간 고생했다.

당연한 이야기일지도 모르지만, gitlab-plugin을 사용해 연계시켰을 때에, 호출원의 PUSH의 정보등은 환경 변수에 들어가 있다.

그것을 깨닫지 않고 어떻게 하면 좋을지를 상당히 고민했다. 공식 문서를 읽는 중요한. .

이번에 사용하는 jenkins의 플러그인은

gitlab-plugin(1.5.4)

htps : // 기주 b. 코 m / 지 킨 킨 s 시 / 기 t ぁ b p ぅ 긴 # 푹신한 d ゔ ぁ 리아 b ぇ s

slack-plugin(2.3)

htps : // 우우키. 지킨킨 s. 이오 / ぢ sp y / 지 킨 킨 S / S ぁ CK + P ㅅ 긴

pipeline-utility-steps-plugin(2.0.2)

htps : // 기주 b. 코 m / Zin Kin s Shi / Pipe Nee Uchi Ty-s Ps-P Pegin

하고 싶은 일

시퀀스를 일으키면 다음과 같이 된다.

gitlab에서 JenkinsProject로의 후크

브랜치명으로 규약을 만들고, 그 브랜치를 PUSH했을 때만 Jenkins가 동작해 주었으면 한다.

Jenkins에서 설정

여기에서는 pipeline 프로젝트를 선택하고 있지만, 빌드 트리거가 존재하는 프로젝트라면 무엇이든 좋다.

빨간색으로 채워진 부분이 gitlab이 요청하는 Jenkins의 URL이므로 삼가해 둡니다. Jenkins는 개인 주소로 http에서 작동합니다.

Secret token도 적절하게 Generate 해 두어 둔다.
feature/build_hoge 등이라는 이름의 브랜치가 PUSH되었을 경우에 동작하는 설정이다

gitlab에서 webhook를 허용하기 위하여 어쩌면 グローバルセキュリティの設定 > CSRF対策의 체크를 풀 필요가 있을지도 모른다. (자신의 환경에서는 체크를 해제할 필요가 있었다.)

gitlab에서 설정

프로젝트 설정에서 webhook을 추가합니다.

URL과 SecretToken에는 조금 앞둔 것을 설정한다. Trigger는 Push event만을 설정하고 있다.

SSL Verification(Enable SSL verification)에는 체크를 넣은 상태.
Add Webhook 를 눌러 설정을 추가합니다.

Test하고 소통이 잡히면 OK. 403 오류의 경우 Jenkins의 CSRF 대책을 해제하여 해결할 수 있습니다.

Test 버튼으로부터의 테스트 실행은 master 브랜치가 환경 변수에 더해지는 것 같고, 앞의 Jenkins측의 설정이라면 프로젝트는 실행되지 않는다.

대신에 Jenkinsの管理 > システムログ 에서 확인할 수 있다.

Jenkins 설정

브랜치의 지정은 gitlab-plugin에 의해 설정된 환경 변수를 이용하고 있다.

gitlab에서는 PUSH마다 webhook이 Jenkins에 요청되지만, gitlab-plugin의 설정으로 feature/build.*라는 명명 규약에 따른 브랜치의 PUSH밖에 대상으로 하지 않는다.

또한 Declarative Pipeline를 사용하고 있으므로 gitlab 프로젝트의 어떤 파일을 읽을지라는 설정에서만 살고 있습니다.

여기에서는 Jenkinsfile에 Jenkins에서의 동작을 기술하고 있다.

Jenkins에서 Slack으로 메시지 보내기

Declarative Pipeline의 형식은 여기을 참조하십시오.

Docker와 조합하면 행복해질 수 있다.

slack-plugin을 사용하면 간편하게 slack 통지할 수 있게 된다. slack 작업 공간에 Jenkins 앱을 설치하고 Jenkins에서 slack-plugin 설정이 필요하지만 여기에서는 설명하지 않습니다.

slack 통지의 attachments 를 이용하기 위해서는 JSON을 이용해야 하지만, 별로 스마트하지 않은 방식으로 밖에 자신은 쓸 수 없었다.
readJSON 또는 readFile를 사용하려면 pipeline-utility-steps-plugin을 사용해야합니다.

또, Decralative Pipeline에는 그들을 직접 기술할 수 없기 때문에, script 블록으로 둘러싸고, pipeline script의 서식으로 기술할 필요가 있다.

pipeline {
//  agent {
//    dockerfile {
//      args "-it --user root"
//    }
//  }
  stages() {
    stage('my stage') {
      steps() {
        slackSend "ビルド開始 - ${env.JOB_NAME} ビルド#${env.BUILD_NUMBER} (<${env.BUILD_URL}|Open>)"
        echo "execute something!!"

        script {
          def attachments = './attachments.json'
          def json_data = readJSON(file: './default_slack_attachments.json')
          def _text = readFile("./result.txt")


          //slackSendの引数のattachmentsに与えるJSON文字列をあまりスマートでないやり方で生成する
          //  1. json_dataを書き出す
          //     文字列onlyと変数展開した文字列を連結するとGroovyはStringとして認識してくれる
          json_data[0]['title'] = "ビルド終了" + " - ${env.JOB_NAME} " + "ビルド#${env.BUILD_NUMBER} 結果は添付しています" + " (<${env.BUILD_URL}|Open>)"
          json_data[0]['text'] = _text
          writeJSON(file: "${attachments}", json: json_data)

          //  2. json stringとして読み込む
          def attachments_string = readFile("${attachments}")
          echo "${attachments_string}"
          slackSend channel: "#jenkins", attachments: "${attachments_string}"
        }
      }
      post {
        success {
          archiveArtifacts artifacts: 'result.txt', fingerprint: true
          deleteDir()
        }
        failure {
          slackSend "ビルド失敗 - ${env.JOB_NAME} ビルド#${env.BUILD_NUMBER}"
          deleteDir()
        }
      }
    }
  }
}

Happy CI & CD!

origin은 여기