팀 프로젝트를 진행하면서 Jenkins를 활용한 CI/CD 환경을 구축하는 중인데, release 브랜치에 merge가 되면 테스트 서버에 CI/CD가 되고, main 브랜치에 merge가 되면 운영 서버에 CI/CD가 되도록 설정하고 있었습니다. 그런데 프론트엔드 코드와 백엔드 코드가 하나의 레포지토리로 관리되다 보니 기존에는 프론트엔드의 배포와 백엔드의 배포가 하나의 job에서 이루어지고 있었습니다.
이는 굉장한 낭비일 수 밖에 없는데요, 백엔드 쪽에만 수정 사항이 있고 프론트엔드 쪽에는 수정 사항이 없을 때 조차도 프론트엔드 코드를 빌드하고 배포하는 과정이 들어가기 때문입니다.
그래서 Jenkins에서 특정 분기를 통해 프론트엔드와 백엔드 중 선택해서 빌드를 할 수 있는 방법이 없을까 찾아보았지만, 사용중이었던 GitHub hook trigger for GITScm polling 방식으로는 마땅한 방법을 찾을 수 없었습니다. 결국 GitHub hook trigger for GITScm polling을 포기하고 Generic Webhook Trigger를 도입하여 PR에 달린 라벨을 기준으로 빌드하도록 설정하는데 성공하여, 해당 방법을 공유드리려 합니다.
사전 준비
Generic Webhook Trigger는 순정 Jenkins로는 사용이 불가능하고, 플러그인을 설치해주어야 합니다. 설치 가능한 플러그인 중 Generic Webhook Trigger Plugin을 찾아서 설치하도록 합시다.
그리고 당연하게도 GitHub 레포지토리에 접근할 수 있는 Credentials가 있어야 합니다. GitHub Credentials를 연동하는 방법은 이 게시물을 참고해주세요.
Jenkins Item 생성
대시보드에서 새로운 Item을 눌러 새 Job을 생성하도록 합시다. 저희는 따로 파이프라인을 사용하지 않고 freestyle을 사용했습니다.
우선은 기존에 Freestyle project를 생성하던 방식대로 작성해주시면 되는데요, GitHub Project 정보를 등록해주도록 하겠습니다.
아래에 소스 코드 관리가 있는데요, 당연한 소리겠지만 Git을 골라주도록 합시다. 레포지토리 URL을 입력해주고, 해당 레포지토리에서 발급받고 Jenkins에 등록한 Credentials를 선택해주면 됩니다. 그리고 Branches to build가 있는데요, 여기에는 빌드할 브랜치를 지정해줄 수 있습니다.
빌드 유발 설정
이제 아래로 내려가서 빌드 유발을 찾아보도록 합시다. (영어로는 Build Trigger 입니다.) 앞서 말했던 플러그인을 잘 설치했다면 Generic Webhook Trigger가 있을 텐데요, 선택해주도록 하겠습니다.
이제 빌드를 유발할 기준이 되는 값들을 설정해줄 차례입니다. 그전에 우선 GitHub Webhook을 이해하고, 설정하고 넘어가셔야 합니다. 잠시 GitHub로 넘어가 GitHub Webhook을 생성하도록 하겠습니다. GitHub에 있는 프로젝트 레포지토리의 Settings - Webhooks에 들어간 뒤, 가운데 보이는 Add webhook 버튼을 클릭하여 webhook을 생성합니다.
이 때 webhook을 보내줄 URL을 지정해야 하는데요, Generic Webhook Trigger를 사용하기 위해서는 토큰 값이 필요합니다. 사진에 보이는 URL 자리에는 Jenkins URL을 적어주면 되고, 토큰 값은 이제 작성해보도록 하겠습니다. 다시 Jenkins GUI로 돌아가주세요.
아래로 쭉 내려가면 Token 탭이 보입니다. 이 칸에 토큰으로 사용할 문자열을 적어주고, GitHub로 돌아가서 webhook URL의 {TOKEN} 자리에 같은 문자열을 넣어주도록 합시다.아래에는 Which events would you like to trigger this webhook?라 하여 webhook의 트리거를 결정해줄 수 있는데요, Send me everything.을 고르고 Jenkins에서 동작을 빌드 유발 트리거로 한 번 더 걸러서 사용할 수도 있지만, PR에 대해서만 webhook을 보내도록 하고 싶다면 Let me select individual events.의 Pull Requests만 선택해주면 됩니다. 이렇게 하면 PR과 관련된 모든 작업(open, close, label, unlabel...)에 대해 webhook을 Jenkins로 보내게 됩니다.
webhook을 생성했으니 빌드 유발을 할 트리거를 설정해주어야 합니다. GitHub가 보내준 webhook에서 트리거를 뽑아내기 위해서는 Post content parameters를 지정해주어야 합니다. PR이 merge가 되었는지 여부를 MERGED라는 이름의 환경 변수로 지정하도록 하겠습니다.
이 때, 위에서 webhook을 받을 방식을 application/json으로 설정했기 때문에 JSONPath를 사용해줍니다. webhook의 payload에서 JSONPath를 사용해 원하는 값을 가져오면 되는데요, 주로 사용하는 값의 JSONPath로는
$.action: webhook 생성을 유발한 동작. 예를 들어 만약 PR을 닫았을 때 만들어진 webhook이라면closed값이 들어있다.$.pull_request.base.ref: PR의 base 브랜치(merge 대상이 되는 브랜치) 이름$.pull_request.merged: PR이 merge되었는지 여부$.pull_request.labels..name: PR에 달린 라벨들의 이름
등이 있습니다. 만약 JSONPath가 헷갈린다면 https://jsonpath.com/ 를 참고하는 것도 좋은 방법입니다.
라벨을 기준으로 하여 빌드를 유발하는 예제지만, 그래도 기본적으로 PR이 merge된 상태일 경우에 빌드가 되도록 설정해주도록 하고 싶습니다. 그리고 release 브랜치에 대해 PR을 close 하는 경우에만 빌드가 되도록 설정하고 싶습니다. 위에 리스트업 한 4개의 값을 각각 ACTION, REF, MERGED, LABEL 이라는 이름의 환경변수로 설정해주도록 하겠습니다.
이제 이 값들을 원하는 값이 들어왔는지 필터링 해줄 차례인데요, 아래로 쭉 내려가면 Optional filter가 있습니다. 여기의 Expression에는 정규표현식을, Text에는 정규표현식으로 검사할 환경변수들을 넣어주면 됩니다. 환경변수 값을 넣어주기 위해서는 $변수명을 사용하면 됩니다.
혹시나 정규표현식이 헷갈린다면 https://regexr.com/ 를 통해 검사하고 넘어가도록 합시다!
이제 설정은 끝났습니다. 이후로는 Build Steps와 빌드 후 조치를 프로젝트와 환경에 맞게 적절히 작성해주고 Jenkins Item 생성을 완료하면 됩니다. 이제 PR을 merge 할 때 특정 라벨이 붙은 상태로 merge하는 것을 조건으로 CI/CD를 진행할 수 있습니다. 여기서는 PR close, 브랜치 명, merged, 라벨 이름을 기준으로 빌드를 유발했지만, GitHub가 제공하는 webhook의 데이터가 굉장히 많기 때문에 다양한 트리거를 만들 수 있습니다.
참고자료
https://bepoz-study-diary.tistory.com/385
https://zayson.tistory.com/entry/Jenkins-CICD-4-WebHook%EC%9D%84-%EC%9D%B4%EC%9A%A9%ED%95%9C-%EC%9E%90%EB%8F%99-%EB%B0%B0%ED%8F%AC
