Pull Request를 병합하기 전에 코드 검사하기

원활한 협업을 위해 ESLint나 Prettier 등의 도구를 활용하곤 합니다. 하지만 이를 로컬에서만 실행되게 하면 '설치하지 않는다', '무시한다' 등의 옵션이 존재하기도 하고, 설치가 제대로 되지 않았으나 설치가 된 줄 알고 작업하는 불상사가 벌어질 수도 있습니다. 더불어, 테스트 케이스 수준에서 걸러지는 오류를 처리하는 등 자동화할 수 있는 작업들을 Pull Request 시에 자동으로 처리하는 방법에 대해 알아보고자 합니다.

스크립트 추가

"scripts": {
    "lint": "eslint 'src/**/*.ts'",
    "lint-diff": "eslint $(git diff --name-only --diff-filter=duxb origin/$BASE origin/$HEAD | grep -E '\\.((j|t)sx?)$' | xargs)"
},

npm run lint를 입력하면 src 아래 모든 파일을 검사하도록 했습니다.
지금 목적은 Pull Request 시 리뷰를 돕기 위함인데, 위 스크립트 하나만 있으면 요청자가 작성하지 않은 파일도 모두 검사하게 됩니다. 내가 하지도 않은 일로 털리는 건 많이 억울하니, git diff를 통해 현재 브랜치와 Pull Request 대상 브랜치를 비교해 변경된 파일 중 .js, .jsx, .ts, .tsx 파일만 검사하는 lint-diff 스크립트도 추가했습니다.

스크립트의 --dif-filter=duxb는 특정 파일들을 검사하지 않기 위해 추가했습니다.

• d: Deleted
• u: Unmerged
• x: Unknown
• b: Broken

입니다. 자세한 옵션은 git-diff 문서에서 확인하실 수 있습니다.

$BASE가 어떤 변수인진 후술하도록 하겠습니다.

workflow 생성

name: Check code with eslint
 
on:
    pull_request:
        branches:
            - master
 
jobs:
    check:
        runs-on: ubuntu-latest
        steps:
            - uses: actions/checkout@v1
            - uses: actions/setup-node@v3
              with:
                  node-version: "16"
                  check-latest: true
            - name: Check
              run: |
                  npm ci
                  npm run lint-diff
              env:
                  CI: true
                  BASE: ${{ github.base_ref }}
                  HEAD: ${{ github.head_ref }}

간단하게 master 브랜치에 Pull Request 할 때마다 lint-diff를 수행하도록 workflow를 만들어봤습니다.
check-on-pr.yml 등의 이름으로 .github/workflows 폴더에 추가해주면 잘 작동합니다.

github.base_ref는 Pull Request 대상 브랜치, github.head_ref는 Base 브랜치에 반영시키고 싶은 브랜치입니다.

정상적으로 작업이 진행되었다면, Pull Request를 생성했을 때 workflow가 실행되고, Pull Request 페이지나 Actions 페이지에서 결과를 확인할 수 있습니다.
아직 베타긴 하지만, 커밋 메시지를 눌러보면 어느 부분에 어떤 오류가 있는지도 상세히 표시해줍니다.

브랜치 보호

이제 확인은 자동으로 진행되지만, 모든 검사가 완료되지 않아도 Merge pull request 버튼이 활성화된다는 문제가 있습니다.

Settings > Branches > Branch protection rules에서 Add rule 버튼을 클릭하면 보이는 화면입니다.
"Require status checks to pass before merging"을 클릭한 뒤, 아래 검색창에 workflow의 이름을 입력하면, 해당 작업이 진행되어야 특정 브랜치에 커밋할 수 있도록 브랜치가 보호됩니다.

Branch name pattern에 쓸 수 있는 패턴은 About branch protection rules를 참고해주세요.

이제 자동화된 작업 선에서 거를 수 있는 문제가 있는 코드는 브랜치에 들어오지 못하게 됐습니다.
물론 관리자가 강제로 병합할 순 있지만요.

모든 확인이 끝나면 Merge pull request 버튼이 활성화됩니다.

본문에선 ESLint만 다뤘지만, 상술한 것처럼 테스트 케이스 등 자동화된 작업 선에서 거를 수 있는 문제 대부분은 위 방법으로 걸러낼 수 있습니다.

사족

Rome이란 Rust로 작성된 도구가 있습니다. formatting, linting, bundling 등 작업을 빠른 속도로 수행할 수 있고, Prettier와 달리 코드에 문제가 있어도 formatting을 수행합니다.
아직 개발이 진행 중이지만 혹시 관심 있으면 확인해보세요!