TL;DR

Rubocop은 캐시 파일을 생성하고 두 번째 이후에는 차등 스캔을 수행합니다. GiuHub Actions의 캐시 기능을 사용하면 캐시 파일을 유지하면 실행 시간을 크게 줄일 수 있습니다.

Rubocop 캐시

Rubocop은 스캔 속도를 높이기 때문에 실행 후 홈 디렉토리의 .cache 아래에 캐시 파일을 생성합니다. 규칙에 변경사항이 없는 경우 두 번째 이후의 스캔은 변경된 파일만 검사합니다.
GitHub Actions는 환경이 매번 지워지므로 GitHub Actios의 캐시 기능을 사용하여 Rubocop의 캐시 파일을 유용하게 사용할 수 있습니다.

설정 예(발췌)

.github/workflows/rails.yml

    - name: Cache rubocop
      uses: actions/cache@v1
      with:
        path: ~/.cache/rubocop_cache
        key: ${{ runner.os }}-rubocop-${{ github.head_ref }}
        restore-keys: |
          ${{ runner.os }}-rubocop-
          ${{ runner.os }}-rubocop-${{ github.base_ref }}
          ${{ runner.os }}-rubocop-${{ hashFiles('**/.rubocop.yml') }}
    - name: Rubocop
      run: bundle exec rubocop --parallel

설정 내용

Rubocop 앞에 지정합니다. 캐시 키워드를 무엇으로 만드는지 문제가 있지만 끌어 오기 요청을 트리거로 이동하므로 "소스 분기 이름"> "대상 분기 이름"> "rubocop.yml 해시"라는 순서로 지정합니다. .
가능한 한 캐쉬를 유효하게 사용하고 싶은 곳입니다만, 캐쉬 생성시와 현재의 코드 차분이 커지면, 결국 스캔하는 파일수가 증가해 버립니다.
따라서 일반적으로 소스 브랜치 이름을 키에 캐시하고 처음 실행하는 브랜치의 경우 대상 브랜치의 캐시를 사용합니다. 타겟 브랜치의 캐쉬도 없는 경우는 .rubocop.yml 의 해시를 키로 한 캐쉬를 사용합니다.
이를 통해 분기별로 다른 캐시를 사용하여 효율적으로 테스트할 수 있습니다.

--parallel 옵션

본근과는 관계 없습니다만, rubocop에 --parallel 옵션을 부여하면(자) 병렬 실행됩니다.
GitHub Actions가 실행되는 환경은 2vCPU이므로 빨라집니다.

효과

차이가 없는 코드로 실행해 보았습니다.

설정 전

1분 27초가 소요

설정 후

3초만에 끝났어