브랜치가 main을 병합하면 테스트 명세 잠금이 main의 테스트를 잡는다

[Jang990]

목표

main 을 병합한 브랜치가 테스트 명세 잠금에서 헛되이 실패하는 것을 없앤다.

지금 방식

.github/workflows/ci.yml 의 테스트 명세 잠금 스텝은 테스트를 먼저 쓰고 나중에 고치는 것을 막는다.

막는 방법은 파일 목록 비교다. PR 의 첫 커밋과 지금을 나란히 놓고, tests/ 안에서 달라진 파일이 있으면 실패시킨다.

FIRST=$(git rev-list ${BASE}..${HEAD_SHA} | tail -1)
git diff --name-only ${FIRST}..${HEAD_SHA} -- tests/

이런 문제가 생긴다

비교하는 두 시점 사이에 브랜치가 main 을 병합하면, main 이 들고 온 테스트 파일도 달라진 파일로 잡힌다.

• 월요일 — chore/A 를 딴다. tests/ 에 파일이 10개다.
• 화요일 — chore/A 가 첫 커밋을 올린다. 비교의 기준점이 여기가 된다.
• 수요일 — 동료가 테스트 파일 2개를 main 에 올린다. chore/A 와 상관없는 작업이다.
• 목요일 — chore/A 가 main 을 병합한다. chore/A 의 tests/ 가 12개가 된다.
• 금요일 — CI 가 화요일과 지금을 비교한다. 파일이 2개 늘었으므로 실패시킨다.

chore/A 는 테스트를 하나도 고치지 않았다. 늘어난 2개는 동료가 쓴 것이다.

이외에도 이런 경우가 있다

목요일의 병합은 작정하고 하는 일이 아니어도 일어난다.

• PR 페이지의 Update branch 버튼을 누른다
• main 과 충돌이 나서 푸는 과정에서 병합한다
• main 에 들어간 수정을 브랜치에도 반영한다

#36 이 막은 것은 이것과 다른 경로다. 깃허브가 검사할 때 자동으로 만드는 머지 커밋을 막았고, 사람이 직접 병합하는 위 세 경우는 그대로 남아 있다.

그래서 이렇게 고친다

파일 목록을 비교하지 않는다. 이 PR 이 직접 만든 커밋만 모으고, 첫 커밋을 뺀 나머지가 tests/ 를 건드렸는지 본다.

main 에서 온 커밋은 이 목록에 들어오지 않는다. 그래서 병합을 해도 잡히지 않는다.

완료 조건

• main 을 병합한 브랜치에서 test 잡이 통과한다.
• 첫 커밋 이후 tests/ 를 고치면 여전히 실패한다. main 을 병합한 브랜치에서도 실패한다.
• 리베이스한 브랜치는 지금처럼 통과한다.
• 위 셋을 실제 CI 실행으로 확인한다.

건드리지 않을 것

• npm test · e2e 잡
• tests/fixtures/ 예외 규칙
• src/, tests/
• 스텝을 그대로 두고 "최신화는 리베이스로 한다" 를 CLAUDE.md 규약으로 세우는 방향. 이 이슈는 스텝을 고친다.

관련

• PR 도중 main에 들어온 테스트를 잠금 검사가 잘못 잡는다 #36 · PR 도중 main에 들어온 테스트를 잠금 검사가 잘못 잡는다 #37 — 같은 원인의 다른 경로
• main 최신화와 병합된 로컬 브랜치 정리를 커맨드로 만든다 #35 — 이 문제로 막혔던 PR. 리베이스로 통과시켰다.