[GIT] GitLab 에서 Renovate 를 이용하여 자동으로 의존성 버전을 관리해보자

소개

Renovate 는 쉽게 말하면 자동화된 의존성 업데이트 도구다. GitHub 로 따지자면 dependabot 같은 역할로 보면 된다.
해당 도구로 의존성 버전을 자동으로 관리해주게 하여 보안 이슈 등으로 인한 라이브러리 버전 업데이트 발생 시 개발자가 버전을 관리하는 부분을 어느 정도 신경쓰지 않도록 도와준다.

 

dependabot의 경우 GitHub을 built-in 의존하는 부분이 있지만, renovate 의 경우 멀티 플랫폼 및 여러 언어에서 동작할 수 있도록 지원하며 커스터마이징도 쉽다. (봇 비교 문서)

Renovate

dependabot

GitLab 의 경우, https://gitlab.com/renovate-bot/renovate-runner 를 통해 사용할 수 있으며 해당 저장소에서 제공하는 템플릿 파일을 통해 renovate 를 쉽게 이용할 수 있다.

 

만약, GitLab Self-Hosting 으로 이용할 경우 저장소를 복사하거나 직접 파일을 가져와야 한다. 해당 저장소를 단순하게 포크하거나 미러링해서 가져오는 방법이 쉽다.

 

사용법

Renovate 실행 환경 설정

renovate-runner 저장소 미러링 및 구성

먼저 https://gitlab.com/renovate-bot/renovate-runner 저장소를 fork 하거나 미러링할 저장소를 만들어준다. 그리고 스케줄러를 돌릴 저장소 하나도 같이 만들어준다.

미러링 저장소 하나, 스케줄러 저장소 하나

스케줄러 저장소에서 CI/CD 를 이용하여 미러링된 저장소를 주기적으로 업데이트하거나 실제 Renovate 를 이용할 저장소의 의존성 버전을 체크할 것이다.

미러링 저장소는 renovate-runner 라고 이름을 지었고, 스케줄러 저장소는 renovate-scheduler 라고 이름을 지었다.

 

액세스 토큰 발급

GitLab 은 아래의 액세스 토큰 중 하나로 이용 가능하다.

• Personal Access Token (PAT)
• Group Access Token
• Deploy Token

적용하기를 원하는 GitLab 그룹의 액세스 토큰을 발급한 후(scope는 api) 기억을 해둔다. 액세스 토큰 이름은 나중에 커밋 author에 포함되니 대충 짓지 말자.

 

스케줄러 저장소 브랜치 구성

다음으로, 스케줄러 저장소에서 브랜치를 두 개로 분리한다. 하나는 master, 다른 하나는 update 로 브랜치를 분리해준다.

master 는 renovate 실행 용도이고, update 는 미러링 저장소의 업데이트 용도이다. GitLab CI 의 Scheduler 기능을 이용해서 브랜치에 따라 주기적으로 실행시킬 것이다.

 

CI/CD 스크립트 작성

master 브랜치에서는 아래와 같이 스크립트를 작성한다. include 의 project 항목은 미러링 저장소를 지정해주자.

include:
    - project: GitLab그룹/renovate-runner
      file: /templates/renovate.gitlab-ci.yml

renovate:
    rules:
        - if: '$CI_PIPELINE_SOURCE == "schedule"'
        - if: '$CI_PIPELINE_SOURCE == "push"'
        - if: '$CI_PIPELINE_SOURCE == "web"'

간단하게 얘기하면 위의 스크립트는 미러링 저장소의 templates/renovate.gitlab-ci.yml 을 include 를 하는 용도 말고는 없다. 스케줄러를 통해 실행되도록 규칙을 지정해놓았다.

 

update 브랜치에서도 아래와 같이 스크립트를 작성한다.

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE != "schedule"
      when: never
    - when: always

variables:
  ORIGIN_GIT_URL: https://gitlab.com/renovate-bot/renovate-runner.git
  MIRROR_GIT_URL: https://gitlab-ci-token:${RUNNER_CI_TOKEN}@GitLab주소/GitLab그룹/renovate-runner.git

stages:
  - update-runner

update-runner:
  stage: update-runner
  image:
    name: alpine/git
    entrypoint: [""]
  cache:
    paths:
      - mirror
  script:
    - if [ ! -d "mirror" ]; then git clone --mirror ${ORIGIN_GIT_URL} mirror; fi;
    - cd mirror
    - git remote add --mirror=fetch mirror ${MIRROR_GIT_URL} || true
    - git fetch origin
    - git push mirror --all --force

위의 RUNNER_CI_TOKEN 변수는 위의 액세스 토큰을 이용할 것이다. 나중에 GitLab CI Schedulers 기능에서 직접 변수를 설정하여 전달할 것이다.

위의 스크립트는 간단하게 얘기해서 미러링된 저장소를 원본 저장소에 따라 내용을 갱신하도록 하는 작업이 작성되어 있다.

 

스케줄러 등록

스케줄러 저장소에서는 아래처럼 일정을 등록해놓았다.

 

미러링 저장소(renovate-runner)를 갱신할 일정은 아래처럼 구성한다.

RUNNER_CI_TOKEN 에서는 위에서 발급한 액세스 토큰을 기입한다. 또는 미러링한 저장소의 액세스 토큰을 넣을 수도 있다.

브랜치가 update 임을 신경쓰자.

 

renovate 가 실제로 적용될 저장소 일정은 아래처럼 구성한다.

변수는 RENOVATE_TOKEN, RENOVATE_EXTRA_FLAG을 넣어줄 수 있다.

RENOVATE_TOKEN 은 위에서 발급받은 액세스 토큰을 넣고,

RENOVATE_EXTRA_FLAG 는 예를 들면 특정 저장소에서만 이루어지도록 할 경우

some_group/some_repository some_group/some_repository2

위와 같이 이용 가능하며, 그룹 기준으로 한꺼번에 동작하도록 하고 싶을 경우

--autodiscover=true --autodiscover-filter=group1/*

와 같은 방식으로 설정이 가능하다.

 

주의할 점은 위에서 사용하는 액세스 토큰이 참조할 그룹 또는 저장소가 해당 저장소에 접근이 가능해야 한다.

 

선택적으로 GITHUB_COM_TOKEN 도 설정이 가능하다. 설정을 하면 나중에 Renovate 가 MR 내용에 Release Note 도 같이 작성을 해준다.

의존성 버전 업데이트 시 해당 의존성의 release note를 GitHub로부터 가져오게 되는데, 액세스 토큰을 하지 않고 익명으로 가져오게 되면 API 호출 한도에 따라 제한적으로 가져오게 된다. 그러므로 액세스 토큰 내 scope 아무것도 설정할 필요없으니 단순히 액세스 토큰을 이용한 조회를 자유롭게 할 수 있도록 GitHub 액세스 토큰 설정을 권장하고 있다.

Release Notes 작성을 해준다.

 

이렇게 하면 GitLab 에서 Renovate 가 실행되는 환경 설정은 끝났다.

 

Renovate 사용

위에서 스케줄러가 동작될 때 프로젝트 저장소에 처음으로 접근하게 되면 해당 저장소에 온보딩 MR이 생기게 되며, renovate.json 이라는 파일이 변경사항에 생기게 된다.

renovate는 각 저장소 내에 있는 renovate.json 파일을 참고하여 해당 설정에 따라 작동된다.

온보딩 MR

renovate.json 파일은 최초에 아래와 같은 내용을 담고 있다.

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:recommended"
  ]
}

해당 파일에는 어떻게 renovate 가 저장소를 관리할지 설정으로 지정해줄 수 있다. 프리셋과 옵션을 두어 설정할 수 있다.

• 기본 preset - https://docs.renovatebot.com/presets-config/
• 사용 가능한 옵션 목록 - https://docs.renovatebot.com/configuration-options/

위의 MR을 통해 병합한 후 해당 저장소의 기본 브랜치에 renovate.json 파일이 있다면 저장소 내의 파일을 분석하여 의존성 업데이트 MR을 자동으로 올리게 된다.

 

그리고 이슈 목록에 아래처럼 Dependency Dashboard(의존성 대시보드) 이슈가 생기게 된다.

의존성 대시보드

현재 열려있는 의존성 업데이트 MR 이나 브랜치 등을 삭제해서 Closed MR한 것, 현재 감지한 의존성 관리 파일 등을 정리해서 보여준다.

이곳에서 Rebase 또는 이전에 닫은 의존성 MR을 다시 활성화시킬 수 있다.

 

기타 사항

 

• 기본적으로 renovate 가 한 번 동작할 때 최대로 생성하는 MR 개수는 최대 2개까지 제한된다. prHourlyLimit 이라는 옵션으로 조정이 가능하나, CI 시스템에 부하를 줄 수 있기 때문에 기본적으로 제한을 두고 있다.
• 기본적으로 semantic versioning에 따라 의존성 버전을 파악한다. 임의적으로 versioning을 설정해야 한다면 https://docs.renovatebot.com/modules/versioning/ , https://docs.renovatebot.com/configuration-options/#versioning 를 참조해서 packageRules의 versioning 항목을 직접 설정해야 한다.
• 사내 Nexus 에서 관리하는 라이브러리가 있다면 이 또한 지원한다.
• 버전이 변경되면 애플리케이션이 동작되지 않을 수 있으므로 MR 또는 브랜치가 생성되면 반드시 CI 설정으로 애플리케이션이 잘 작동되는지 미리 확인할 수 있도록 설정하자.
• 의존성 관리 매니저에 있는 라이브러리 버전에 따라 MR이 생성되고, GitLab 이슈에 의존성 대시보드가 생성되는데 이곳에서 의존성이 관리된다.
• 만약, 아직 병합하지 않은 MR이 있고 이 상태로 의존성 관리 매니저에서 해당 라이브러리 버전이 삭제된다면 해당 MR도 나중에 자동으로 close 처리된다.
• 만약, 병합하고 싶지 않은 MR이 있다면 브랜치를 삭제하거나 MR을 Close 처리하면 된다. 이렇게 할 경우 GitLab 이슈에 생성된 의존성 대시보드에 아래와 같이 항목이 생기게 되는데, 다시 MR에 등록하고자 할 경우 체크박스에 체크하고 다시 CI가 돌아올 때까지 기다리면 나중에 다시 등록된다.