[Gerrit, Jenkins] Gerrit과 Jenkins 연동

최근에 회사에서 FE 작업을 하면서 내가 작업한 내용에 대한 CI/CD 자동화 설정을 진행하려고 시도하고 있다.

그런데 사내 시스템 자체가 Gerrit을 사용하고 있기 때문에 Gerrit과 Jenkins를 연동하는 방법에 대해 설명하려고 한다.

 

1. Jenkins 설치

먼저, 나는 WSL 환경이고 Ubuntu 22.04를 사용하고 있다.

Jenkins는 java 환경에서 동작하기 때문에 jdk를 설치해준다.

나는 비교적 최신의 Jenkins를 사용할 것이기 때문에 jdk 17을 설치했다.

sudo apt update
sudo apt install openjdk-17-jdk -y

 

Jenkins 저장소의 GPG 키를 추가하고, 소스 리스트에 추가해주자.

curl -fsSL https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key | sudo tee \
  /usr/share/keyrings/jenkins-keyring.asc > /dev/null
  
echo deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc] \
  https://pkg.jenkins.io/debian-stable binary/ | sudo tee \
  /etc/apt/sources.list.d/jenkins.list > /dev/null

 

이제 저장소가 업데이트 되었으니 Jenkins를 설치하자.

sudo apt-get update
sudo apt-get install jenkins -y

 

이제 Jenkins를 실행해주자.

wsl이기 때문에 service 명령어를 쓴다.

sudo service jenkins start

 

jenkins는 8080 포트니까 localhost:8080으로 접속하면 된다.

무슨 Initial 비밀번호를 입력하라고 하는데, cat으로 알려주는 파일의 내용물을 보면 된다.

sudo cat /var/lib/jenkins/secrets/initialAdminPassword

 

계정을 생성하고 그냥 권장 설정으로 설치를 갈겼다.

 

2. Gerrit 설정

Gerrit 설치 내용은 내가 이전에 썼던 게시글들을 참고하면 좋을 것 같다.

https://se-dobby.tistory.com/115

[Gerrit] 게릿 설치 및 적용: 나만의 깃, 코드 리뷰 시스템 구축하기

 

본격적으로 Gerrit을 설정해보자.

일단 Jenkins를 설치하게 되면 wsl에 jenkins 계정이 생긴다.

sudo -u jenkins -s

 

이렇게 사용자를 전환해주고, ssh-key를 생성한다. 이 키는 gerrit에 등록할 키다.

ssh-keygen -t rsa

 

/var/lib/jenkins/.ssh/id_rsa.pub의 내용물을 복사해서 들고 있자.

 

그리고 Gerrit에서 jenkins용 계정을 생성해주자.

나는 현재 Gerrit이 htpasswd를 기반으로 사용하고 있기 때문에 다음의 명령어로 사용자를 생성했다.

sudo htpasswd {.htpasswd 파일 경로} {사용자명}

 

그리고 설정에서 아까 생성한 ssh-key를 등록해줬다.

 

아, 그리고 ssh로 Gerrit에 한 번 접속을 해서 ssh 연결을 기억해두어야 한다.

그렇지 않으면 추후에 Jenkins가 실행될 때 ssh로 pull을 받아오지를 못한다.

ssh -P 29418 jenkins@gerrit.com

계정과 gerrit의 주소는 각자 설정에 따라 달라지게 될 것이다.

어쩌구 저쩌구 문구가 뜨면 yes를 입력하면 known_hosts에 등록이 완료된다.

 

그러고 나서 중요한 절차가 필요하다.

Gerrit 관리자 계정으로 들어가서 방금 생성한 jenkins용 게릿 계정을 Service User 그룹의 멤버로 등록한다.

그러고나서 이 계정이 이벤트나 점수를 달 수 있도록 권한을 설정해줘야 한다.

 

All-Projects의 Access 탭에서 권한을 조금 수정해주자.

 

1)

 

2)

 

3)

 

이제 Gerrit에서의 설정은 모두 완료되었다.

 

3. Jenkins 설정

먼저, Jenkins의 설정 - Plugins에서 Gerrit Trigger라는 플러그인을 설치해주자.

설치가 완료되면 설정페이지에서 Gerrit Trigger가 보일 것이다.

 

이걸 들어가 New Server로 게릿 서버를 추가해주자.

 

Hostname과 Frontend URL (Gerrit 접속 URL) 을 잘 입력해주고 username은 아까 생성한 Jenkins 용 게릿 계정 이름을 적는다.

그리고 SSH Keyfile은 ssh-keygen으로 생성된 키의 기본 경로로 세팅되어 있으므로 건드릴 필요가 없다.

 

최신의 Gerrit에서는 Verified 항목이 없어진 상태다. 그래서 우리는 Code-Review 점수를 줄 것이기 때문에 아래로 좀 내려보면 있는 Code-Review 항목에서 점수를 설정해주자.

 

그러고 나서 아래 Gerrit Verified Commands에서 --verified <> 로 설정되어있는 것들을 전부 지워주자.

사진에 나와있지 않는 항목들도 전부 제거하면 된다.

 

마찬가지로 조금 더 내리다 보면 있는 Verdict Categories에서도 Verified를 제거하자.

아래처럼 남겨놓으면 된다.

 

이러면 Save를 누른다.

Status를 한 번 클릭했을 때 초록색 체크표시가 뜨면서 Version이 보이면 제대로 설정된 것이다.

 

3. Gerrit 프로젝트와의 연결

우리는 Pipeline을 쓸 것이다.

그래야지 Jenkinsfile로 작성된 스크립트를 원하는대로 작성해 커스텀하는 것이 가능하다.

아래부터는 캡처로 설정을 대신하겠다.

 

1) Trigger

여기서 Project Path에는 Trigger를 유발할 프로젝트 이름과

Branch Path는 그 프로젝트 중에서도 Trigger를 유발할 브랜치 이름을 적으면 된다.

 

그 다음에는 Pipeline과 연관이 있는 SCM 설정이다.

REFSPEC에 입력하는 내용은 게릿에서 패치셋이 갖는 고유한 참조 값이다.

그게 있어야지만 트리거를 유발한 녀석의 변경을 추적하는 것이 가능한 것이다.

 

 

여기서 $GERRIT_BRANCH의 경우 코드 리뷰가 어떤 브랜치에서 일어났는지 정보를 담고 있다.

결국 앞서 설정한 $GERRIT_REFSPEC와 $GERRIT_BRANCH 두 개가 잘 설정되어 있어야지 특정 브랜치의 특정 패치셋에 대한 정보를 가져올 수 있는 것이다.

 

Jenkinsfile이 프로젝트 root 위치가 아니라 conf.d 폴더 안에 있으면 conf.d/Jenkinsfile 이런식으로 설정하면 된다.

 

이렇게 하면 Gerrit과 Jenkins 연동이 끝났다.

실제로 Jenkinsfile을 작성해 올려둔 상태에서 Patchset을 만들면 Jenkins가 점수를 달아주는 것을 볼 수 있다.

 

4. NodeJS 설치

혹시 NodeJS가 필요한 사람들은 다음과 같이 하면 된다.

 

설정 - Plugins에서 Nodejs를 검색해서 설치한다.

그러고 나서 설정 - tools에서 쭈욱 아래에 내려보면 Node JS가 생긴다. 여기서 내가 설치하고 싶은 버전을 설치하고 name을 잘 설정해준다.

추후, Pipeline의 Script를 작성할 때 어떤 node js를 사용할지 결정할 때 이 name으로 결정이 난다.

 

5. Jenkinsfile 예시

내가 작성한 Jenkinsfile은 다음과 같다.

pipeline {
    agent any
    tools {
        nodejs 'name'
    }

    stages {
        stage('Checkout Gerrit Patchset') {
            steps {
                echo "Fetching and checking out the exact patchset: ${env.GERRIT_REFSPEC}"
                checkout([
                    $class: 'GitSCM',
                    branches: [[name: "${env.GERRIT_REFSPEC}"]],
                    userRemoteConfigs: [[
                        url: 'ssh://jenkins@gerrit.com/SampleProject',
                        refspec: "+${env.GERRIT_REFSPEC}:${env.GERRIT_REFSPEC}"
                    ]]
                ])

                echo "Checkout complete!"
                sh 'git log -1'
            }
        }

        stage('Install Dependencies') {
            steps {
                script {
                  def changed = sh(script: "git diff --name-only HEAD~1 HEAD | grep 'package.json' || true", returnStdout: true).trim()
                  if (changed) {
                        echo "📦 package.json changed, running npm install..."
                        sh 'npm install'
                  } else {
                    echo "✅ package.json unchanged, skipping npm install."
                  }
                }
            }
        }

        stage('Build Project') {
            steps {
                sh 'npm run build'
            }
        }
    }
    post {
        success {
            echo "✅ Deployment successful!"
        }
        failure {
            echo "❌ Deployment failed."
        }
    }
}

 

대충 변경사항 Pull 받고, npm install 하고, npm run build하는 내용이다.

 

이때, checkout scm을 안하는 이유는 이 간단한 명령어로는 scm에 등록된 깃 레포의 디폴트 브랜치만 주구장창 빌드가 된다.

그래서 설정한 환경 변수들을 이용해서 위와 같이 checkout 을 진행하면 내가 원하는 브랜치에 대해서 작동하는 것이 가능하다.

Gerrit Trigger에서 관심 대상 브랜치를 지정해주면 해당 브랜치의 변경사항에 대해서만 작동하기 때문이다.

 

또, npm install을 매번 하는 건 불필요하기 때문에 diff에서 package.json의 변경사항이 있을 때만 npm install을 하도록 하여 빌드 타임을 줄였다.

제대로 빌드가 되면 위와 같이 상태가 뜬다.

옆에 Console Output 에서 명령어 실행 결과들을 훑어볼 수 있다.

 

Retrigger로 해당 트리거를 재실행하는 것이 가능하다.

Restart from Stage로 특정 Stage부터 다시 실행하는 것도 가능하다.

 

 

첫 테스트에서 Fail이 떠서 -1을 받았다가 수정 후에 빌드가 잘 되니까 +1점을 받은 것을 볼 수 있다.

 

참고할 것

나는 처음에 Jenkins 용 Gerrit 계정을 따로 만들지 않았다.

그냥 내 Gerrit 계정을 등록해둔 것이다.

그랬더니 빌드도 안되고 리뷰도 달리지 않았다.

알고보니 자기 자신의 변경 사항에 대한 리뷰는 달리지 않는 것이었다.

 

그 이유는 Jenkins가 어떤 패치셋에 대해서 리뷰를 달면, 이로 인해 이벤트가 발생해서 또 트리거가 작동되고 또 리뷰를 하는 식으로 무한 루프에 빠지게 된다.

물론 이벤트 필터를 잘 관리해서 직접 관리할 수도 있지만, 그건 복잡할 수 있다. 그래서인지 그런 일이 애초에 일어나지 않도록 Gerrit Trigger 플러그인에서 예방을 하고 있다.

따라서, Jenkins와 Gerrit을 연동할 때는 Gerrit용 계정을 별도로 꼭 꼭!! 만들어 주자.