[Android] Github action을 이용한 CI(ktlint)

이번 프로젝트에서 Github Action이라는것을 알게되고, CI를 적용해보았다.

 

CI

CI(Continous Integration)

지속적인 통합

 

CI를 제대로 구축하면 코드의 새로운 변경사항을 레포지토리에 적용할때마다 테스트,ktlint등 검사를 할 수 있다.

우리팀과 같은 경우 코틀린 컨벤션을 지키는 Ktlint를 CI로 구축해서 특정 브랜치에 push나 PR을 날릴 경우

Github action으로 등록한 workflow에 따라 자동으러 검사를 한다.

 

우리는 Git flow 전략에 따라서 develop  브랜치에 PR을 날릴때마다 작성한 코드의 코틀린 컨벤션을 검사한다.

위 사진과 같이 error를 감지할 경우 어디서 컨벤션을 지키지 않았는지 알 수 있다.

팀 그라운드룰로 Kotlin Convention을 정했지만, 더 확실하게 하고 싶어서 해당 CI를 적용해봤습니다.

하지만 해당 CI를 적용하기 까지 많은 어려움이 있었습니다..

 

Gradle 및 Test는 검사하고 싶지 않아!

우리가 검사하고 싶은 타깃은 src 폴더에 있는 소스 코드 파일들이었다.

물론 Gradle, Test 코드 모두 다 컨벤션을 지켜야하지만 gradle 파일과 test 파일에 대한 컨벤션은 정하지 않아서 검사를 하고 싶지 않았다.

ktlint action을 그대로 적용하니 소스 코드를 제대로 작성하더라도 gradle과 test 코드에서 매번 검사를 당했다.

적용한 CI에서 ktlint에 어긋나는 코드가 있으면 Merge를 금지하였기 때문에 컨벤션을 검사하는 범위를 지정해줬어야 했다.

 

어떻게 범위를 지정해야할까에 대해서 많은 고민을 팀원들과 했었다.

안드로이드 버전이 올라가면서 gradle 파일도 kts 확장자를 가지게 되었다.

따라서 우리팀은 소스 코드가 있는 경로만을 타겟삼아서 검사했다.

아래는 Github Action으로 생성한 yml 파일이다.

소스 코드

name: AOS-ktlint
on:
  pull_request:
    branches:
      - main
      - AOS-develop
  push:
    paths:
      - '**.kt'
jobs:
  ktlint:
    name: AOS-ktlint
    runs-on: ubuntu-latest
    steps:
      - name: checkout mindsync
        uses: actions/checkout@master
        with:
          fetch-depth: 1
      - name: ktlint
        uses: ScaCap/action-ktlint@master
        with:
          github_token: ${{ secrets.github_token }}
          reporter: github-pr-check

 

 

on

동작과 브랜치를 지정해서 특정한 이벤트가 발생하면 자동으로 실행이 된다.

위 코드에선 PR을 main과 AOS-develop에 보내면 ktlint Check를 하거나, 확장자가 kt 파일인 경우 ktlint 검사를 한다.

jobs

Action에서 실행할 구체적인 동작을 의미한다.

runs-on

어떤 OS에서 실행될것인지에 대한 명시이고, 대부분의 yml 파일은 ubuntu의 최신버전을 이용하기에 따라갔다.

steps

작업이 실행될 순서인데

https://github.com/ScaCap/action-ktlint

GitHub - ScaCap/action-ktlint: Run Ktlint with reviewdog

우리팀은 위 사이트에서 사용하는 ktlint Action을 적용했다.

 

안드로이드에선 더 다양한 CI를 적용할 수 있다.

빌드 전에 clean을 해서 gradle 오류를 해결하거나, Gradle 빌드를 자동화하거나, test 코드의 테스트를 자동화하는 다양한 CI가 있다.

 

Github Action에서 Android를 검사하면 보편적으로 사용되는 CI Action이 있다.

 

해당 CI 파일을 기준으로 각자 프로젝트에서 적용하고 싶은 Action을 커스텀해서 사용할 수 있다.

 

느낀점

처음 사용할때는 이런게 무슨 자동화..?라고 생각했지만 Action에서 추가한 작업에 따라서 다양하게 사용할 수 있다는것을 느꼈고, 처음에 잘 정의한다면 엄청나게 편할것 같다.

Ktlint를 검사하는 단순한 CI를 적용했지만 코틀린 컨벤션을 계속해서 검사하고, 지키지 않았다면 Merge를 금지시키는 브랜치 룰을 적용해서 코드의  품질을 높일 수 있었다.

가끔 브랜치를 pull 하면 gradle이 동기화 되지 않았거나, 정상적인 코드가 빨간줄을 표시하는등 자잘한 오류가 발생하는데 CI를 통해서 해결할 수 있다는것을 듣고 다양한 CI를 적용해서 작업의 불편함을 개선하고 싶다.