자바로 GitHub Actions 라이브러리 만들기

팀 프로젝트를 하다 보면 PR이 올라온 뒤 리뷰가 지연되는 경우가 종종 있다. 바쁜 일정 속에서 PR을 까먹기도 하고, 언제까지 리뷰해야 하는지 기준이 없으면 자연스럽게 흐지부지되기도 한다. 이러한 문제를 팀에서 인지하고, 코드 리뷰에 2일이라는 제한 시간을 두기로 했다. 하지만, 결국 이것도 머리로 기억해야 하는 문제였다.

 

그래서 PR에 마감일을 시각적으로 표시해주면 어떨까 생각했다. D-2, D-1, D-Day 같은 라벨이 PR에 붙어있으면 리뷰어 입장에서도 기억하지 않아도 쉽게 확인할 수 있고, 남은 기간에 대해서 긴박함을 느낄 수 있을 것이다.

 

도입하기 전에 먼저 이미 있는 액션 라이브러리들을 찾아보았다. 유력했던 후보가 네이버에서 만든 d-day-labeler였는데, 이건 마감일을 따로 지정할 수 없었고 특정 PR에 대해서 라벨을 업데이트 할 수가 없었다. 즉, 모든 PR에 대해서만 라벨 업데이트를 지원하는 스크립트였다.

 

우리 팀에 맞게 커스텀 하는 방안이 필요했고, 그래서 직접 GitHub Actions를 라이브러리로 만들어보았다.

 

자바를 선택한 이유

기본적으로 액션 스크립트에 모든 과정을 자바스크립트나 타입스크립트로 만들 수도 있다. 그리고 이러한 액션 스크립트 내에 몰아넣는 방식이 싫다면 GitHub Actions Toolkit을 이용해 GitHub Actions에 특화된 편의 기능과 함께 라이브러리 형태로 만들어 사용할 수도 있다.

 

하지만, 두 방식 모두 공식적으로 자바스크립트와 타입스크립트만 지원한다. 근데 본인이 자바스크립트를 잘 모르기도 해서 현재 상황에서는 가독성과 재사용성 측면에서 매우 비효율적이라고 판단했다. 그래서 익숙한 자바를 이용해 만드는 방법을 생각했다.

 

자바는 액션을 만들려면 Docker container action 방식을 써야 한다. 이는 GitHub Actions runner에 JVM이 없으니 직접 Docker 환경을 구성하고, 그 안에서 자바 앱을 실행하는 방식이다. 단점이기는 하다만 해당 작업이 속도가 중요한 액션이 아니기도 해서 충분히 트레이드오프 가능한 지점이라고 생각했다.

 

개발 과정

요구사항을 먼저 정리해보았다.

- PR이 생성될 때 자동으로 라벨을 붙인다.
    - 기본적으로 D-2의 라벨을 붙인다.
- 매일 자정에 기존에 존재하는 PR의 라벨 정보를 가져온다.
    - 라벨 정보를 토대로 D-1, D-Day, Over-Due 라벨로 업데이트 한다.
    - 이때, 이미 Over-Due라면 라벨을 업데이트 하지 않는다.
    - D-n 관련 라벨이 없다면, D-2 라벨로 업데이트한다.
- PR에 리뷰가 달리면 라벨을 D-2로 업데이트 한다.

 

간단하게 요구사항을 먼저 정리하고 나서 코드를 바로 작성하기보다는 요즘 조영호님의 '오브젝트' 책을 다시 읽고 있어서 '책임 주도 설계(RDD)' 관점으로 접근해보았다. 먼저, 나올만한 도메인 용어들을 정리해보았는데 아주 간단했다.

• PullRequest
• Label

이외에도 마감일, 생성일, 경과일 같은 용어들도 생각했는데, 구현 세부사항 같아서 제외했다. 그 후에는 시스템이 수행해야 할 메시지를 도출했다.

PR의 라벨을 붙여라

 

이 메시지를 받을 적절한 역할은 PullRequest다. PR이 자신의 정보를 가장 잘 알고 있으니까. 그런데 PR이 메시지를 받았을 때 혼자 할 수 없는 것들이 있다. 어떤 라벨을 붙여야 하는지 계산하는 책임과 실제로 라벨을 부착하는 책임이 필요했고 이 시점에서 새로운 객체가 도출됐다.

• LabelPolicy: 기준일 기반으로 라벨을 계산하는 책임
• LabelAttacher: 실제로 라벨을 부착하는 책임

PR은 이 두 가지를 각각 LabelPolicy와 LabelAttacher에게 위임한다. LabelAttacher는 GitHub API를 호출해야 하는데, 이건 인프라 관심사다. 도메인이 인프라를 알면 안 되니 인터페이스로 분리하고 구현체를 외부로 뺐다.

 

 

그 결과 이러한 형태의 도메인 협력 구조를 만들 수 있었다. 그리고 PR을 가져와 처리하는 조율이 필요했는데, 이 책임은 LabelingService가 맡았다. PR 목록을 가져오는 책임은 PullRequestRepository 인터페이스로 분리했다.

 

처음엔 마감일을 D-2로 고정해두었는데, 팀마다 코드리뷰 문화가 다를 수 있다는 생각이 들었다. 어떤 팀은 3일, 어떤 팀은 5일을 기준으로 삼을 수도 있으니까. 그래서 deadline-days를 외부에서 받도록 설계를 바꿨다. LabelPolicy 생성 시 주입받는 방식이라 도메인 로직은 전혀 건드리지 않아도 됐다.

LabelPolicy labelPolicy = new LabelPolicy(Long.parseLong(deadline));

 

5일로 설정하면 D-5 → D-4 → D-3 → D-2 → D-1 → D-Day → OVER-DUE 흐름으로 동작한다.

 

Docker container action 구성

자바 앱을 GitHub Actions에서 실행하려면 Docker 환경이 필요하다. 멀티 스테이지 빌드로 최종 이미지를 가볍게 유지했다.

FROM gradle:8.5-jdk21 AS build  
  
WORKDIR /app  
COPY . .  
RUN gradle jar --no-daemon  
  
FROM eclipse-temurin:21-jre-jammy  
  
WORKDIR /app  
COPY --from=build /app/build/libs/deadline-labeler-0.0.1.jar app.jar  
  
ENTRYPOINT ["java", "-jar", "/app/app.jar"]

 

첫 번째 스테이지에서 빌드하고, 두 번째 스테이지에서 jar만 가져와 실행한다. 최종 이미지에 Gradle이나 소스 코드가 포함되지 않는다. 한 가지 빠진 게 있었는데, jar 태스크에 Main-Class를 명시하지 않으면 java -jar로 실행할 때 진입점을 못 찾는다.

tasks.jar {
    manifest {
        attributes["Main-Class"] = "Main"
    }
    from(configurations.runtimeClasspath.get().map {
        if (it.isDirectory) it else zipTree(it)
    })
    duplicatesStrategy = DuplicatesStrategy.EXCLUDE
}

 

action.yml

구성 액션의 인터페이스를 정의하는 파일이다. 외부에서 어떤 값을 넘길 수 있는지, 그리고 어떻게 실행되는지를 명시한다.

name: 'PR Deadline Labeler'
description: 'PR 코드리뷰 마감일 기반으로 라벨을 자동 부착합니다.'

inputs:
  github-token:
    required: true
    description: 'Github 접근을 위한 토큰'
  base-date:
    required: false
    description: '업데이트를 위한 기준일자'
  pr-number:
    required: false
    description: '업데이트하고자 하는 PR 번호'
  deadline-days:
    required: false
    default: '2'
    description: '코드리뷰 최대 마감일 지정'

runs:
  using: 'docker'
  image: 'Dockerfile'

 

runs.using: 'docker'로 설정하면 GitHub Actions가 레포지토리에 명시된 Dockerfile을 빌드하고 실행한다. inputs에 정의된 값들은 컨테이너 안에서 'INPUT_변수명'형태의 환경변수로 주입된다. 예를 들어 'github-token'은 'INPUT_GITHUB-TOKEN'으로 접근할 수 있다.

String token = System.getenv("INPUT_GITHUB-TOKEN");

 

워크플로우 구성

세 가지 트리거에서 동작하도록 의도했다. 각각 pull request 생성, cron 스케줄, pull request 리뷰 등록 시점이다.

on:
  pull_request:
    types: [opened]
  schedule:
    - cron: '0 15 * * *'  # KST 00:00
  pull_request_review:
    types: [submitted]

 

각 트리거별로 적절한 baseDate를 액션에 넘겨준다. 액션은 트리거를 모르고 baseDate만 받는다. 권한 설정도 빠뜨리면 안 된다. 기본적으로 GITHUB_TOKEN은 읽기 권한만 있어서 라벨 쓰기가 안 된다.

permissions:
  issues: write
  pull-requests: write

 

마치며

정말 팀의 필요에 의해서 개발을 하다보니 되게 재밌는 경험이었다. 그리고, 이러한 액션으로 가져올 변화가 굉장히 기대가 된다. 기회가 된다면 이를 따로 글로 작성할 생각이다.

 

개발 얘기를 좀 하자면 책임 주도 설계를 제대로 해본 것은 처음인데 책임 주도 설계로 시작하니 코드 작성 전에 구조가 명확해졌다. 도메인이 인프라를 전혀 모르는 구조를 자연스럽게 만들 수 있었고, 어디에 어떤 코드가 있어야 하는지 고민할 필요가 없었다.

 

조영호님은 코드 배치를 따로 두고 객체지향을 말할 수는 없다 했는데, 이번에는 단순했기 때문에 자연스럽게 협력의 구조가 그대로 코드의 배치와 알맞지 않았나 싶다. 어쨌든 이렇게 자바스크립트 없이 자바로도 GitHub Actions을 만들 수 있다. Docker container action이라는 방식이 있으니까.

 

현재 각종 버그를 수정하고 v1.0.0가 릴리즈됐고, 다른 레포에서 아래처럼 바로 사용할 수 있다.

- uses: kkiseug/pr-deadline-labeler@v1
  with:
    github-token: ${{ secrets.GITHUB_TOKEN }}
    base-date: ${{ github.event.pull_request.created_at }}
    pr-number: ${{ github.event.pull_request.number }}
    deadline-days: 5

 

 

GitHub - kkiseug/pr-deadline-labeler: PR의 D-Day 라벨을 등록 및 관리해주는 액션 라이브러리