통합 워크플로우 #29
통합 워크플로우 #29
Conversation
| beforeAll(() => { | ||
| vi.spyOn(console, "error").mockImplementation(() => {}); | ||
| }); | ||
|
|
||
| afterAll(() => { | ||
| vi.mocked(console.error).mockRestore(); | ||
| }); |
There was a problem hiding this comment.
테스트 결과에 어지럽게 에러 로그가 출력되지 않도록 하기 위함입니다.
- before
- after
|
각 동작이 waterfall로 실행되는 걸까요? 만약 그렇다면 그것을 혹시 의도하신 걸까요? |
@sounmind 좋은 질문 감사합니다! waterfall 이라고 보실 수도 있지만 short circuit이라고 보실 수도 있을 것 같아요. 예를 들어, 코드 포멧팅 조차 안 되어 있는 코드를 상대로 굳이 lint, coverage나 build를 돌리는 것은 제한된 GitHub Actions의 billable time만 낭비할 수 있으니까요. 이미 프로젝트에 husky와 pre commit 설정이 되었으니 대부분의 문제는 개발자가 로컬에서 commit을 할 때 잡힐 것입니다. 통합 워크플로우는 주로 개발자가 미처 로컬에서 발견하지 못했거나, 커밋을 할 때 저는 처음에는 워크플로우를 단순하게 가져가다가 오래 걸리는 단계가 생기면 별도 작업으로 빼는 것을 선호하는 편입니다. 느린 단계는 병렬로 돌리면 개발자에게 더 빠른 피드백을 줄 수 있기 때문입니다. 하지만 우리 프로젝트의 경우, Bun이 말도 안 되게 빨라서 모든 단계를 실행하는데 20초도 안 걸리는 상황입니다. 우선 하나의 작업으로 시작하고 나중에 프로젝트가 커져서 빌드 시간이 증가한다면, build만 따로 돌리도록 워크플로우를 수정하면 어떨까요?
|
|
와, 상세하고 친절한 설명 감사합니다. 의도를 충분히 파악했습니다 |
PR에 새로운 commit을 push 할 때 마다 자동으로 코드 포멧, 린트, 테스트 (커버리지), 빌드를 실행해주는 워크플로우를 추가합니다. 이 중에 하나라도 실패하게 되면 PR을 머지할 수 없게 됩니다. 이러한 자동화를 통해 코드 베이스의 최소한의 품질을 확보하며 불필요한 리뷰 코멘트를 방지합니다.