Release Note 자동 생성하기 (with Release Drafter)

저번 글에서는 릴리즈 노트를 어떻게 작성하면 좋은지에 대해서 카카오엔터프라이즈의 글을 읽으면서 정리를 했다.

 

이번 글은 릴리즈 노트를 자동 생성하는 방법에 대해서 공유하려고 한다.

 

결론부터 말하자면, 깃헙 액션의 Release Drafter을 사용해서 특정 라벨의 PR이 main에 머지되었을 때 릴리즈 노트에 각 기능별로 항목이 생기게할 수 있다.  그러면 "우리가 이번 배포까지 어떤 일을 했는지" 알 수 있어, 좀 더 편하게 릴리즈 노트를 관리할 수 있다.  

---

1. 설정 파일 등록하기

파일 위치랑 이름은 문서에 나와있는 그대로를 활용하였다.

 

파일 위치 : .github/workflows/release-drafter.yml

name: Release Drafter

on:
  pull_request:
    branches:
      - main
    types:
      - closed

jobs:
  update_release_draft:
    runs-on: ubuntu-latest
    steps:
      - uses: release-drafter/release-drafter@v5
        with:
          config-name: release-drafter-config.yml
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

 

주절주절에서는 dev 브랜치에서 main 브랜치로 merge를 할 때 일반머지를 한다. 그래서 배포를 할 때 각각의 커밋들이 그대로 쌓이게 되는데, 이를 활용해서 릴리즈 노트에서 어떤 작업을 했는지 쌓으면 좋지 않을까? 라는 생각이 들었다. 그래서 on에 "PR이 main 브랜치에 closed 될 때 릴리즈 노트에 기록"하는 조건을 명시했다. types을 merged로 썼을 때 github actions가 원하는대로 동작하지 않았다 🥲

 

GITHUB_TOKEN이 꼭 필요하므로, 개인의 Settings > Developer setting > Personal access tokens에서 토큰이 있는지 확인해보아야 한다. 하지만, 주절주절은 개인 레포가 아니라서, 팀 계정 레포의 Settings > (Actions) secrets에 예전에 등록한 서브모듈의 Access Token을 사용해서 적용하였다. (어떻게 등록했는지 모름..)

 

2. 템플릿 설정 파일 등록하기

릴리즈 노트에 작성될 템플릿 설정은 config 파일에서 할 수 있다. config 파일은 반드시 .github 폴더 알에 있어야한다.

 

파일 위치 : .github/release-drafter-config.yml

name-template: "v$NEXT_MINOR_VERSION 🌈"
tag-template: "v$NEXT_MINOR_VERSION"
categories:
  - title: "🚀 Features"
    labels:
      - "🕹 기능"
      - "⚒ 리팩토링"
  - title: "🐛 Bug Fixes"
    labels:
      - "🐞 버그"
exclude-labels:
  - "⚙️ 설정"
  - "🌈 프론트"
  - "🍻 테스트"
  - "🔥 백엔드"
  - "📋 문서"
  - "🚨 이슈"
change-template: "- $TITLE (#$NUMBER)"
change-title-escapes: '\<*_&'
template: |
  ## Changes

  $CHANGES

 

설정파일에서 반드시 필요한 부분은 template이다. 실제로 릴리즈 노트에 어떻게 기록이 될 지 정하는 템플릿이다.

 

릴리즈 노트의 형태

 

위에 있는 설정파일에 따르면, 제목과 태그는 이전 릴리즈 버전의 다음 마이너 버전을 한단계 올려서 생성된다. 만약 이전 릴리즈의 버전이 v1.0.0 이었다면, 이후에는 v1.1.0으로 자동생성 된다.

 

주절주절에서는 배포 때 주로 마이너 버전을 올리기 때문에 설정을 위와 같이 했는데, 팀에 따라서 또는 설정에 따라서 패치 부분이나 메이저 부분을 업데이트 시킬 수도 있고, 현재의 버전을 알려주게 할 수도 있다.

 

기능(Feature), 버그 픽스, 사용되지 않는 부분에 title을 작성하고 해당하는 라벨을 아래에 명시하면  $CHANGES에 내용이 담기게 되어 결론적으로 위 사진의 모습이 된다. 

 

실험과정이 있었는데, 블로그에 적기에는 내용이 많은 것 같아서 🖇 노션을 참고해주면 감사하겠습니다 :)

 

3. 유의해야 할 점

혼자서 실험할 때는 문제가 없어서 몰랐는데, 메인 브랜치로 보내는 PR이 closed 될 때 적용되어야하니깐 main에 바로 PR을 보내면 되는것으로 이해해서 다음과 같이 PR을 보내고 머지시켰다.

그러자 github Action 쪽에서 에러가 발생했고 원인을 살펴보니,"template" is required였다. 분명 템플릿도 위치도 파일명도 몇번이나 확인한 건데 무슨 일일까 하면서 고민하면서 찾아본 결과 검색을 통해 github action은 default branch를 기준으로 동작한다는 것을 알게되었다...! (주절주절 팀에서는 개발이주로 이루어지는 곳이 develop 브랜치이기 때문에 defualt branch를 main이 아닌 develop으로 해두었다.)

 

 안절부절하다가 새벽에 만능팀원1에게 도움을 요청하여, main에 머지된 commit들을다시 develop에 머지하는 방식으로 해결했다.

---

참고한 사이트

Release Drafter - GitHub Marketplace

"ValidationError: child "template" fails because ["template" is required]\n' · Issue #835 · release-drafter/release-drafter