[fix]: scope build-and-test concurrency by event to avoid cancellations

[sf-tyler-jeong]

Summary

Release-branch commits trigger build-and-test from both the push (release/**) and pull_request (synchronize) events. Both shared the same concurrency group (build-and-test-<branch>), so cancel-in-progress: true made them cancel each other — one run ended cancelled, which left the required build-and-test status check unsatisfied and blocked the release PR merge (hit on the v3.18.0 attempt).

Fix

Add ${{ github.event_name }} to the concurrency group so push-triggered and PR-triggered runs land in separate groups and no longer cancel each other. Per-event cancellation of superseded runs is preserved, so CI savings on rapid pushes are kept.

-  group: build-and-test-${{ github.head_ref || github.ref_name }}
+  group: build-and-test-${{ github.event_name }}-${{ github.head_ref || github.ref_name }}

🤖 Generated with Claude Code

[netlify]

✅ Deploy Preview for sendbird-uikit-react ready!

Name	Link
🔨 Latest commit	142f8b9
🔍 Latest deploy log	https://app.netlify.com/projects/sendbird-uikit-react/deploys/6a18da52058af6000989ac86
😎 Deploy Preview	https://deploy-preview-1435--sendbird-uikit-react.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[danney-chun]

이거 혹시 release branch에서 CHANGELOG_DRAFT의 내용을 CHANGELOG로 옮기고 commit/push하는 거 때문에 발생하는 이슈인가요?
그게 원인이라면 release-workflow의 순서를 바꾸는 게 더 좋을 것 같습니다.

release branch build-test가 성공 -> merge to main -> CHANGELOG Update -> commit/push -> npm publish

[sf-tyler-jeong]

이거 혹시 release branch에서 CHANGELOG_DRAFT의 내용을 CHANGELOG로 옮기고 commit/push하는 거 때문에 발생하는 이슈인가요? 그게 원인이라면 release-workflow의 순서를 바꾸는 게 더 좋을 것 같습니다.

release branch build-test가 성공 -> merge to main -> CHANGELOG Update -> commit/push -> npm publish

원인 분석 감사합니다! 다만 release-workflow reorder 방향엔 두 가지 우려가 있어 다른 접근으로 갔는데 의견 부탁드려요.

1. main 직접 push는 branch protection에 막히기 쉽고, bot 우회가 권장 패턴이 아닙니다.
2. CHANGELOG finalize commit이 release atomic commit에서 분리되어 main에 별도 commit으로 남게 됩니다.

대신 build-and-test의 trigger 자체에서 double-fire 원인을 제거했습니다. push: 브랜치에서 release/**를 제거. release branch의 CHANGELOG commit은 PR이 열려있는 한 pull_request:synchronize로 1회만 build-and-test를 발화하므로 충돌이 사라집니다. release-workflow.yml은 변경 없고, CHANGELOG commit도 release atomic 그대로 유지됩니다.

이렇게 가도 될지 의견 부탁드립니다!
감사합니다.

[danney-chun]

이거 혹시 release branch에서 CHANGELOG_DRAFT의 내용을 CHANGELOG로 옮기고 commit/push하는 거 때문에 발생하는 이슈인가요? 그게 원인이라면 release-workflow의 순서를 바꾸는 게 더 좋을 것 같습니다.
release branch build-test가 성공 -> merge to main -> CHANGELOG Update -> commit/push -> npm publish

원인 분석 감사합니다! 다만 release-workflow reorder 방향엔 두 가지 우려가 있어 다른 접근으로 갔는데 의견 부탁드려요.

1. main 직접 push는 branch protection에 막히기 쉽고, bot 우회가 권장 패턴이 아닙니다.
2. CHANGELOG finalize commit이 release atomic commit에서 분리되어 main에 별도 commit으로 남게 됩니다.

대신 build-and-test의 trigger 자체에서 double-fire 원인을 제거했습니다. push: 브랜치에서 release/**를 제거. release branch의 CHANGELOG commit은 PR이 열려있는 한 pull_request:synchronize로 1회만 build-and-test를 발화하므로 충돌이 사라집니다. release-workflow.yml은 변경 없고, CHANGELOG commit도 release atomic 그대로 유지됩니다.

이렇게 가도 될지 의견 부탁드립니다! 감사합니다.

push: 브랜치에서 release/**를 제거

release branch를 만든 후 배포 전에 긴급 수정을 해야 하는 상황이 생긴다고 하면 이 push에 대해서는 CI가 검증을 하지 못합니다. 이 부분이 살짝 우려가 되긴 합니다.

CHANGELOG_DRAFT.md를 작성을 하는게, release tag 를 만드는 시점에 body를 채우는데 편의성을 제공 하는 용도 밖에는 없는거 같은데, 차라리 CHANGELOG_DRAFT.md를 제거을 하고 CHANGELOG.md를 Full 로 작성을 해서 release branch를 만들고, release tag를 만들때, 잘 추출해서 하는 방식으로 하는 방법도 나쁘진 않을거 같습니다.

chat-js는 develop-v4가 default branch라서 main이 default branch인 uikit 하고는 조금 차이가 있어 보이네요.

[sf-tyler-jeong]

이전 문제 상황 정리:

release branch에 commit push 시 두 이벤트가 동시 발화했습니다:

• push:release/** → build-and-test 실행
• pull_request:synchronize → build-and-test 실행

둘 다 같은 concurrency group(build-and-test-release/...)에 속하고 cancel-in-progress: true라서, 한 쪽이 다른 쪽을 cancel하는 경합이 발생. 한 run이 'cancelled' 상태로 끝나면 GitHub branch protection의 required check ("build-and-test passing" 요구)가 충족되지 않아 머지가 차단됐습니다 (v3.18.0 release에서 실제 발생).

option A 적용 후:

• push:release/** 제거 → pull_request:synchronize 1회만 발화 → cancel 충돌 없음 → success → required check 통과 → 머지 가능

CI 발화 시점 자체는 그대로 유지됩니다:

1. PR 생성 시점: pull_request:opened → CI 1회
2. release branch에 push (긴급 수정, CHANGELOG finalize 등): pull_request:synchronize → CI 1회
3. merge to main: push:main → CI 1회

검증 빈틈은 없고, 중복 발화로 인한 cancel만 해결됩니다.
이렇게 되서 문제는 없을 것 같은데요. 의견 부탁드려요~

[danney-chun]

이전 문제 상황 정리:

release branch에 commit push 시 두 이벤트가 동시 발화했습니다:

• push:release/** → build-and-test 실행
• pull_request:synchronize → build-and-test 실행

둘 다 같은 concurrency group(build-and-test-release/...)에 속하고 cancel-in-progress: true라서, 한 쪽이 다른 쪽을 cancel하는 경합이 발생. 한 run이 'cancelled' 상태로 끝나면 GitHub branch protection의 required check ("build-and-test passing" 요구)가 충족되지 않아 머지가 차단됐습니다 (v3.18.0 release에서 실제 발생).

option A 적용 후:

• push:release/** 제거 → pull_request:synchronize 1회만 발화 → cancel 충돌 없음 → success → required check 통과 → 머지 가능

CI 발화 시점 자체는 그대로 유지됩니다:

1. PR 생성 시점: pull_request:opened → CI 1회
2. release branch에 push (긴급 수정, CHANGELOG finalize 등): pull_request:synchronize → CI 1회
3. merge to main: push:main → CI 1회

검증 빈틈은 없고, 중복 발화로 인한 cancel만 해결됩니다. 이렇게 되서 문제는 없을 것 같은데요. 의견 부탁드려요~

이해 됬습니다.

[danney-chun]

lgtm~