github-tag-action으로 버전 관리 자동화 (with. anothrNick/github-tag-action)
github-tag-action
anothrNick • Updated Oct 4, 2024
태그 다는 걸 github actions를 이용해 자동화해보자. pr 생성해 merge 하는 방식 기준으로 설명하겠다.
아래는 예시코드다.
설정 변수들에 대해 간단히 설명을 덧붙여보자면, 아래와 같다 (정말 안 쓸 거 같은 변수 3개 정돈 설명에서 제외했다)
- GITHUB_TOKEN (required) - repo에 태그 생성하기 위한 권한 부여받기 위해 필요
- DEFAULT_BUMP (optional) - 명시 안했을 때 사용할 기본 버전 증가 유형 지정(default:
minor).
- DEFAULT_BRANCH (optional) - GitHub Runner 환경 변수에서 default 브랜치를 읽지만, 현재 default 브랜치로 master나 main을 사용 중이지 않다면, 이 변수를 설정하는 것이 좋음. 그렇지 않으면 ‘full’ 기록과 함께 오류가 발생할 수 있음. 즉, 현재 깃허브 상에서 default 브랜치로 develop을 사용하고 있지만, 버전 관리할 때 최종적으로 정식 출시될 default 브랜치는 master로 지정하고 싶다면,
DEFAULT_BRANCH: master라고 명시를 해주자. 버전 관리할 때 사용할 default 브랜치는 actions가 태그를 붙일 때 참조하는 대상이기도 하다. 해당 브랜츠의 최신 커밋을 기준으로 새 태그를 생성하기 때문이다.
- WITH_V (optional) - 버전을 ‘v’ 문자와 함께 태그함
- RELEASE_BRANCHES (optional) - 쉼표로 구분된 브랜치 목록으로, 이 브랜치들에선 태그가 생성됨. 다른 브랜치나 pr에 대해선 commit hash가 붙은 버전이 생성될 뿐 태그는 생성되지 않음(브랜치 목록 예시:
masteror.*orrelease.*,hotfix.*,master)
- CUSTOM_TAG (optional) - 사용자 정의 태그 설정 시 유용함. 예를 들면 도커 이미지에서 FROM 이미지를 기반으로 태그를 생성할 때 사용하면 좋음. 다만, 이 태그를 설정하면 다른 모든 설정이 무효화됨
- INITIAL_VERSION (optional) - 증가 전 초기 버전 설정. 기본값은 0.0.0임. WITH_V와 함께 사용할 경우, 여기에 vX.X.X라고 쓰지 않고 X.X.X라고 써야 한다는 점 주의해야 함
- PRERELEASE (optional) - prelease mode에서 워크플로우가 실행되는지 정의함. 일관성을 위해
ref: ${{ github.sha }}와 함께 사용하셈 ()
- PRERELEASE_SUFFIX (optional) - prelease 버전의 접미사임(default:
beta)
- VERBOSE (optional) - git log를 출력함. 일부 프로젝트에선 이 로그가 매우 클 수 있음 (default:
true)
- commint message string tag: 커밋 메시지에 특정 문자열을 포함하여, 해당 커밋이 버전 번호 어떻게 변경해야 하는지를 지시하는 태그. 만약 커밋 메시지에 ‘#major’가 포함되어 있다면, 다음 태그가 주요 버전 번호 증가시키는 걸 의미함
- MAJOR_STRING_TOKEN (선택) - commint message string tag를 default인
#major에서 다른 것으로 변경함 - MINOR_STRING_TOKEN (선택) - default인
#minor에서 다른 것으로 변경함 - PATCH_STRING_TOKEN (선택) - default인
#patch에서 다른 것으로 변경함 - NONE_STRING_TOKEN (선택) - default인
#none에서 다른 것으로 변경함
작동할 때 알아두면 좋을 것은 bumping이란 용어다. bumping이란 커밋 메시지에 특정 태그(#major, #minor, #patch, #none)을 포함시킬 때, 해당 태그에 따라 버전을 증가시키는 것을 말한다. anothrNick/github-tag-actions의 경우 bumping 관련해 아래 전략을 따른다.
- Manual Bumping : 커밋 메시지에 #major, #minor, #patch 중 하나가 포함되어 있다면 그에 따라 버전 올림. 만약 두 개 이상의 태그가 있다면, 우선 순위 높은 태그를 따름. #none 태그가 있다면 버전을 올리지 않음.
- Automatic Bumping : 커밋 메시지에 태그가 없다면, 설정된 DEFAULT_BUMP에 따라 자동으로 버전을 올림. 기본적으로는 #minor가 설정되어 있음. 이 기능을 끄려면 DEFAULT_BUMP를 none으로 설정하면 됨.
사용법에 대해 설명하자면, 아래와 같은 플로우로 동작한다.
- 사용자가 action을 worflow 코드에 추가한 후, pr을 생성하고 action을 실행시키면 된다.
- action이 가장 최신의 태그를 받아와, 커밋 메시지 내용에 따라 태그의 버전을 증가시키고 github에 push한다.
이때, 알아두면 좋은 점은 default 브랜치 여부에 따른 차이다.
- default 브랜치라면, 즉 최종적으로 릴리즈 노트를 생성할 master 브랜치에 플로우가 동작한 경우, 생성되는 버전 태그는 릴리즈 태그로 간주된다. (ex:
v0.0.1→v0.0.2)
- default 브랜치가 아니라면, 아직 정식으로 출시되지 않은 버전을 의미하는 사전 릴리즈 태그가 생성된다. 이 태그는 PRERELEASE_SUFFIX 를 뒤에 붙여 버전을 구분함 (ex:
v0.0.1-prereleasesuffix1→v0.0.1-preleasesuffix2)
우리 서비스에선 이를 아래와 같이 활용했다.
- 참고
