플러그인 버전을 올릴 때마다 gh release create로 draft를 만들고, 확인한 다음
--draft=false로 발행하는 식으로 릴리스를 해왔다. 근데 오늘 0.89.10, 0.89.11,
0.89.12를 연달아 릴리스하면서 매번 같은 일이 벌어졌다 — 같은 태그로 draft가
두 개씩 생겼다.
세 번 다 그냥 지우고 넘어갔다
0.89.10 Draft
0.89.10 Latest
gh api로 확인해보면 진짜로 release id가 두 개였다. 하나는 내가 방금 만든
정상적인 draft, 다른 하나는 untagged-xxxxx라는 이상한 태그가 붙은 빈 draft.
gh release create가 가끔 중복 생성되는 CLI 버그인가 보다 싶어서, 매번 빈 쪽을
찾아서 지우고 넘어갔다. 세 번 다 그렇게 했다.
CHANGELOG를 쓰다가 이상한 걸 봤다
릴리스가 다 끝나고 CHANGELOG.md를 새로 만들면서, 버전별 릴리스 노트를 쭉
훑어봤다. 0.89.10, 0.89.11은 내가 쓴 노트가 그대로 있는데, 0.89.12만 본문이
비어 있었다.
{"author": "github-actions[bot]", "body": ""}
작성자가 github-actions[bot]이었다. 내가 만든 적 없는 릴리스였다.
원인 — 이미 있던 자동화였다
.github/workflows/ 안을 보니 release.yml이라는 워크플로우가 있었다.
on:
push:
tags:
- '*'
...
- name: Create release
run: |
tag="${GITHUB_REF#refs/tags/}"
gh release create "$tag" --title="$tag" --draft \
main.js manifest.json ...
태그를 push하면 자동으로 빌드하고 draft 릴리스를 만드는, 이 프로젝트에 원래
있던 정식 릴리스 파이프라인이었다. 그러니까 “중복 draft”는 CLI 버그가 아니라,
내가 태그를 push한 직후 수동으로 gh release create를 또 실행하면서 이
자동화랑 매번 경쟁하고 있었던 것이었다.
세 번은 운이 좋았을 뿐이었다
0.89.10, 0.89.11 때는 우연히 “빈 쪽”을 지우고 “내가 쓴 쪽”을 발행해서 문제가 안 보였다. 근데 0.89.12 때는 반대로 걸렸다 — 내가 쓴 노트가 있는 release를 지우고, CI가 만든 빈 release를 그대로 발행해버린 거다. 겉보기엔 릴리스가 정상적으로 끝난 것처럼 보여서, 나중에 노트 내용을 직접 확인하기 전까지는 전혀 몰랐다.
고치고, 프로세스도 다시 봤다
gh release edit 0.89.12 --notes "..."
내용 자체는 복구가 쉬웠다. 근데 이번 일로 알게 된 게 하나 더 있다 — 애초에
npm run build + gh release create를 수동으로 할 필요가 없었다. 태그만
push하면 CI가 알아서 빌드하고 draft를 만들어주니까, 내가 할 일은 그 draft
내용을 확인하고 노트만 채워서 발행하는 것뿐이었다. 몰랐던 자동화 때문에 매번
불필요한 작업을 중복으로 하고 있었던 셈이다.
남는 생각
이상한 걸 세 번 봤는데, 세 번 다 “왜 이러지”를 묻지 않고 증상만 지우고 넘어갔다. 매번 결과가 괜찮아 보였으니까. 근데 그 이상함이 사실은 이유가 있는 동작이었고, 그 이유를 모른 채 계속 손으로 지우다 보니 결국 한 번은 진짜 데이터(내가 쓴 릴리스 노트)를 지우는 쪽으로 걸렸다. 증상이 매번 무해해 보인다고 해서 원인까지 무해한 건 아니라는 걸, 이번에도 다시 배웠다.