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

CI

CI(Continous Integration)

지속적인 통합

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

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

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

https://blog.kakaocdn.net/dn/bA8WxS/btsAWgTCdg3/D4RMW8DZKuuI6uZrqRpEp1/img.png

https://blog.kakaocdn.net/dn/ek3VDq/btsA1bxskLu/Ugq5ovJ4PkSGRAfKUQucXK/img.png

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

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

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

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

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

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

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

https://blog.kakaocdn.net/dn/bG4PWJ/btsAUKOd7FF/lUwrkTq5gtnx5HPhoy0oxk/img.png

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

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

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