Jenkins PR 라벨별로 빌드 유발하기

라벨별로 빌드를 유발해야하는 이유

우리팀의 Github 레포지토리는 백엔드와 프론트 파일을 함께 관리하고 있다. 따라서 어떤 파일이 수정되었던지 간에 상관없이 Develop 브랜치와 Main 브랜치에 PR이 머지되거나 Push가되면 프론트엔드 파이프라인과 백엔드 파이프라인이 모두 돌아가 불필요한 빌드가 실행되는 경우가 있었다. PR의 라벨에 따라 파이프라인이 돌아가도록 설정한다면 이 문제를 해결할 수 있을 것이라고 판단했다.

 

 

기존 설정

파이프라인의 빌드 유발을 설정할 때 보통은 GitHub hook trigger for GITScm polling을 많이 사용할 것이다. 이 설정은 깃허브로부터 Push 훅을 받았을 때 빌드가 유발되는 설정이다. 이 설정은 위에서 설명한 문제점이 있다.

 

라벨별로 설정하기

PR라벨별로 빌드를 유발하기 위해 Generic Webhook Trigger를 선택해준다. 이 옵션이 보이지 않는다면 플러그인에 들어가서 Generic Webhook Trigger를 설치해주면 된다.

 

Github Webhook 수정하기

기존의 Payload URL은 http://{jenkins_url}/github-webhook/ 으로 설정되어있었을 것이다. github-webhook/ 대신 generic-webhook-trigger/invoke로 설정해주자. 그리고 application/json 과 Send me everything을 체크해준다. Send me everything의 설정은 푸쉬에 대한 웹훅뿐만 아니라. PR의 open, close,branch로의 push 등 모든 이벤트를 날리게된다. URL 뒤의 쿼리스트링으로 되어있는 token=token 부분은 아래에서 설정해줄 token 값이다. 파이프라인 설정에서도 친절하게 설명이 나와있다.

빌드 유발 설정하기

다시 파이프라인 설정으로 돌아와서

Post content parameters 추가를 누르고 변수명을 기입하고 JSONPath Expression을 기입한다.

위에서 작성한 Expression은 Github Webhook설정에서 Recent Deliverieds에서 페이로드를 자세히 들여다보면 이해할 수 있다.

그 후, 위의 URL의 쿼리스트링으로 적어줬던 token 부분을 token으로 채워준다. 아래에 설명이 잘 나와있다. 설명처럼 optional인 설정이지만 설정해주지 않았을 때 적용되지 않아 token을 적어주었다.

마지막으로 Expression에는 정규표현식을 Text에는 변수들을 작성해주면 설정이 완료된다. develop 브랜치에, backend라는 라벨로 머지가 된다면 빌드가 유발되도록 설정해둔 것이다.

https://regexr.com/ 에서 테스트 결과 정상적인 정규표현식을 작성한 것을 알 수 있다.

이 후, 깃헙에서 PR에 라벨을 적용하고 merge를 해보면 정상적으로 파이프라인이 돌아가는 것을 확인할 수 있다.

 

마무리

불필요한 파이프라인이 돌아가는 것을 막기 위해 라벨별로 빌드가 유발되도록 설정해보았다. PR을 머지할 때마다 프론트와 백엔드가 동시에 돌아가서 파이프라인이 돌아가는 속도가 느렸는데 비교적 빨라져서 비교적 수월한 CI/CD를 할 수 있게 되었다.

 

 

참고

https://bepoz-study-diary.tistory.com/385