Gitlab Runner로 SonarQube 분석 자동화 하기

이전 포스팅을 통해서 리눅스 서버에 Gitlab, Sonarqube를 설치하고 수동으로 스크립트를 실행해 프로젝트를 Sonarqube를 이용해 정적분석하는 것까지 해보았습니다.

하지만 매번 수동으로 스크립트를 실행하면 매우 번거롭겠죠?
그래서 이번엔 Gitlab Runner를 이용해 Gitlab에 Merge Request(Github의 Pull Request와 같음)가 뜨면 자동으로 정적분석을 실행해 확인하도록 연동해보는 작업을 해보도록 하겠습니다.

각 페이지마다 Gitlab Dosc의 링크를 걸어놓았습니다. ubuntu외에 다른 운영체제 또는 docker등 다른 형태로 Gitlab Runner를 설치하시려는 분들은 참고하시면 될거 같습니다.

Gitlab Runner 소개 - 공식 문서 링크

처음엔 Gitlab에 있는 레파지토리를 SonarQube로 정적분석을 자동적으로 수행하기 위해서 어떤 방법이 있는지 찾아보던중 Runner라는것을 알게되었습니다.
처음엔 Runner가 어떤 역할을 하는건지 이해하기는 어려웠지만 지금은 아주 조금이라도 알게 된거 같습니다.

공식 사이트에 Runner의 소개를 보면 아래와 같이 설명하고 있습니다.

작업을 실행하고 Gitlab에 결과를 다시 보내는데 사용되는 오픈소스 프로젝트입니다.

조금더 풀어쓰면 개발자가 작성한 스크립트를 Runner가 실행 후 결과를 gitlab에 보내는 역할을 한다고 보시면 될거 같습니다.

Gitlab Runner 설치 - 공식 문서 링크

Gitlab Runner를 설치하는 방법은 여러가지가 있지만 제일 간단하고 빠르게 설치하는 방법은 다음과 같습니다.

# gitlab 공식 레파지토리를 추가합니다.
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash

# apt-get을 이용해 runner를 설치합니다.
sudo apt-get install gitlab-runner

설치는 끝났습니다. 아주 간단하죠???
특정 버젼의 runner설치는 링크에 들어가보시면 확인할 수 있습니다.

Gitlab Runner 등록 - 공식 문서 링크

이제는 Gitlab과 Runner를 서로 연결 시켜줘야합니다.
연결 하기 전에 설치한 Gitlab사이트에 들어가서 runner연결을 위한 정보를 확인해야합니다.

프로젝트 레파지토리 -> 왼쪽 메뉴 제일 하단의 Settings 메뉴 CI/CD -> Runners settings 항목 Expand 버튼 클릭

이동 후 에는 아래와 같은 화면이 보일텐데요 이미지 하단의 Setup a specific Runner manually에 있는
URL주소와, 토큰값을 미리 복사해둡니다.

다시 터미널로 돌아와서

# runner 등록 실행.
sudo gitlab-runner register

# 실행되면 아래와 같이 설정값 입력을 해야합니다.

# 복사한 URL을 입력해줍니다.
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):

# 복사한 토큰 값을 입력해줍니다.
Please enter the gitlab-ci token for this runner:

# Runner 설명을 입력해줍니다. gitlab에서 runner를 식별하기 위한 설명 입력입니다. (나중에 변경가능)
Please enter the gitlab-ci description for this runner:

# Runner 태그를 입력해줍니다. 같은 태그를 가진 runner를 동시에 실행 가능하게끔 해준다고 합니다. (나중에 변경가능)
Please enter the gitlab-ci tags for this runner (comma separated):

# 태그되지 않은 빌드를 실행할거냐? 라고 묻는거 같은데 사실 잘 모르겠습니다. (태그안따면 진짜 빌드 안되는기능인지는 나중이 확인해보도록 하겠..)
# default가 false니까 false로 진행합니다.
Whether to run untagged builds [true/false]:

# 런너를 현재 프로젝트에만 잠글꺼냐? 라고 물어보는건데 잠그다의 의미가 현재 프로젝트에서만 사용가능하게끔 할꺼냐 라는 의미로 받아들이면 될거 같습니다.
# 우선 해당 런너는 다른 프로젝트에서 사용하지 않을것이기에 default 값인 true로 진행합니다.
Whether to lock the Runner to current project [true/false]:

# 실행자(?) 선택을 합니다. 프로젝트를 빌드할때 사용할 방식을 선택하는거라 보면 될거같습니다.
# 여기서는 shell을 선택합니다.
# https://docs.gitlab.com/runner/executors/
Please enter the executor: virtualbox, docker-ssh+machine, docker-ssh, parallels, ssh, docker+machine, kubernetes, docker, shell:

# 아래 문구가 나오면 등록 완료!!
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

등록이 완료된 후 Runners Settings 페이지를 다시 열어보면 아래와 같이 러너가 등록이 된걸 확인 할 수 있습니다.

Gitlab Script 작성 - 공식 문서 링크

이제 Gitlab과 Gitlab Runner와 연동은 모두 끝났습니다.
마지막으로 Runner가 어떤 작업을 수행해야하는지 명시해주는 스크립트 작성을 해보도록 하겠습니다. 스크립트 작성시 사용되는 키워드가 여러개가 있어서
이번 포스팅에서 모드 다루기는 어려울거 같구요.

이번 포스팅에선 신규 Merge Request(Github의 Pull Request와 동일합니다.)가 발생했을때 Runner를 수행하는 스크립트를 작성해보도록 하겠습니다.

우선 파일이름은 .gitlab-ci.yml 로 만드시고 아래와 같은 스크립트를 작성하시면 되는데요

sonarqube_job:
  script: ./gradlew sonarqube -Dsonar.host.url=http://127.0.0.1:9000/sonar -Dsonar.login=ABCDEFGHIJKLMNOPQR
  only: 
  - master
  - merge_requests
  tags: 
  - front-dev

위 스크립트를 간단하게 설명하자면 다음과 같습니다.

sonarqube_job : job이름
script : 수행할 스크립트
only : master에 커밋이 push되거나, merge_request요청이 들어왔을때만 해당 작업을 수행한다.
tag : front-dev 태그를 가지는 런너들에서 수행한다.

* 참고로 gitlab 버젼에 따라서 일부 키워드가 실행되지 않을 수 있습니다.
(Gitlab 11.6 버젼부터 merge_requests키워드가 동작합니다. 링크)

이제 작성된 스크립트를 프로젝트에 포함시키고 push 합니다.
push가 완료되면 이 이후부터 master브랜치로 merge request(pull request)가 발생하면 자동적으로 runner가 스크립트를 수행해서 sonarqube로 분석을 요청합니다.

제가 스크립트를 작성하면서 이렇게도 저렇게도 해보면서 확인한 내용중에 아래 두가지는 알고있으면 좋을거 같아서 적어두었습니다.

1. 스크립트는 커밋이 push되면 무조건 동작합니다.
2. target 브랜치가 최소 1개 존재해야 합니다.

이 2가지 입니다. 처음 merge request가 요청들어올때만 실행하고 싶어서 only 키워드에 merge_requests만 넣어놨었는데 그렇게 하니까 No stages / jobs for this pipeline. 에러가 나면서 pipeline 실행이 불가능합니다.
그래서 - master 를 추가해서 2번의 항목을 만족시켰더니 정상적으로 수행은 됩니다.

다만 그럴경우에 1번의 이유로 master에 push가 들어올때도 스크립트가 동작하게 되는데요.
이 포스팅에서는 해당 부분을 인지하고 넘어갔지만 실제로 업무에 사용할땐 저렇게 하면 불필요하게 스크립트가 많이 수행되는거 같아서 스크립트 수행 단계를 각각 나눠서 구성하면 merge request가 발생할때만 sonarqube에 분석을 요청하게끔 만들 수 있을거 같습니다. 참고

위 작업들이 모두다 끝나면 CI/CD 메뉴의 Pipelines에 아래 이미지처럼 동작이 정상적으로 수행되었는지의 유무를 확인 할 수 있고, 수동으로 Pipeline을 동작 시킬 수 도 있습니다.

참고

• https://taetaetae.github.io/2018/02/08/jenkins-sonar-github-integration/
• https://namioto.github.io/2018/07/16/gitlab-ci%EB%A1%9C-%EC%9E%90%EB%8F%99%EB%B0%B0%ED%8F%AC%ED%95%98%EA%B8%B0/
• https://medium.com/@speedforcerun/sonarqube-with-gitlab-ci-setup-stepbystep-java-maven-version-7e131dce0bb1