사내 JavaScript SDK(@acme/web-sdk) 저장소는 3주 전부터 릴리스를 자동화했습니다. main에 머지하면 release 워크플로가 버전을 올려 태그를 push하고, 태그 push를 받은 publish 워크플로가 npm에 배포하는 구조입니다(전에는 사람이 태그를 직접 push했습니다). 그런데 태그는 v1.8.0까지 생겼는데 npm 최신 버전은 여전히 1.5.2이고, 고객사에서 "새 버전이 안 보인다"는 문의가 왔습니다. 동료가 publish.yml의 태그 패턴을 'v*.*.*'로 바꿔 봤지만 다음 릴리스에서도 publish는 시작되지 않았습니다.
태그 push는 됐는데 publish 워크플로가 안 뜸: GITHUB_TOKEN으로 push한 이벤트
사내 JavaScript SDK(@acme/web-sdk) 저장소는 3주 전부터 릴리스를 자동화했습니다.
시나리오
단서
on:
push:
branches: [main]
permissions:
contents: write
jobs:
release:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: |
git config user.name "release-bot"
git config user.email "[email protected]"
npm version minor -m "chore(release): %s"
git push origin main --follow-tagson:
push:
tags: ['v*']
jobs:
publish:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm publishTo https://github.com/acme/web-sdk 4f1c2e9..a83d7b0 main -> main * [new tag] v1.8.0 -> v1.8.0
$ git tag --sort=-v:refname | head -4 v1.8.0 v1.7.0 v1.6.0 v1.5.2 $ npm view @acme/web-sdk version 1.5.2 # Actions 탭: publish 워크플로 마지막 실행 — 21일 전, v1.5.2, 사람이 직접 push
과제 publish가 시작되지 않는 원인을 좁히고, 밀린 버전을 배포하는 순서(검증 포함)와 재발 방지책을 적어 보세요.
구독하면 이어서 볼 수 있어요
이 문제의 전체 시나리오와 점검 체크리스트, 복구 순서, 모범 풀이는 Pro 구독에서 열립니다.
먼저 볼 것
- 이벤트가 '있는지'보다 '누가 만들었는지' 보기
- actions/checkout이 남기는 자격 증명
- 워크플로끼리 이어 붙이는 방법의 차이(이벤트 vs 직접 호출)
점검 체크리스트
- Actions 탭에서 publish 워크플로의 마지막 실행과 그때 push한 주체 확인
- release.yml의 git push가 어떤 자격 증명으로 나가는지 확인(actions/checkout의 persist-credentials 기본값)
- npm view 로 레지스트리 버전과 git 태그 목록 비교
- publish.yml의 on: 트리거에 수동 실행(workflow_dispatch)이 있는지 확인
복구와 재발 방지
같이 보면 좋은 질문
현장에서 본 비슷한 케이스
0/10