TOAST UI Grid에 Github Actions가 함께한다면?🎬

Jung Han
Jung-han
Published in
9 min readJan 31, 2020

Github Actions란?

Github Actions는 Github에서 작년 말 전체 공개되었으며 개발 workflow를 깃헙 자체적으로 자동화할 수 있게 도와주는 도구이다. 코드 버전 관리, 리뷰 뿐만 아니라 테스트, 빌드, 배포 등을 깃헙 한 군데서 관리할 수 있게 된다. 기존에 사용하고 있던 CI 도구들(jenkins, travisCI, circleCI)에서 수행해 주던 역할들을 어느 정도 Github에서 수행해주게 된다. 언어 또한 Node.js, Python, Java, PHP, Ruby, C/C++, .NET, Android, iOS 등을 지원하고 앞으로도 확장될 예정이라고 한다.

액션에서 workflow를 코드로 관리하며 쉽게 수정하고 적용할 수 있다. 빠른 속도와 통합된 환경에서 작업한다는 것은 큰 매력이었다. github actions에는 많은 강력한 기능들이 존재하는데 그 중 여러 환경에서 여러 버전을 통시에 테스트할 수 있는 matrix를 간단하게 살펴보도록 하겠다. 문서에 있는 예시를 가져왔다.

여러 노드 버전과 여러 OS 환경에서 병렬적으로 npm을 설치하고 빌드하고 테스트하게 된다. 이렇게 테스트를 한 결과는 즉각적으로 action탭에서 확인 할 수 있다.

뚝딱뚝딱 돌아가는 모습을 실시간으로 볼 수 있다.

언제 action이 발생할까?

주로 webhook에 의해 발생한다. 여기서 webhook이라면 github에 push나 PR이 왔을 때부터 이슈가 올라오고, 이슈에 댓글이 달리거나, 라벨이 달리거나, 마일스톤이 변경되는 등등을 의미한다. 단순히 해당 이벤트뿐만 아니라 좀 더 구체적으로 삭제 되었을 때 추가되었을 때 등을 지정해서 action을 발생하게 할 수 있으며 추가로 개인이 webhook을 만들 수 있다.

또한, 스케줄링 또한 지원한다. POSIX 크론 구문으로 작성하면 된다. 시간은 최소 5분 간격 까지 가능하다고 한다.

그 외 외부 dispatch로도 실행 시킬 수 있다.

요금은?

MS 만세 🙆‍♂

오픈소스는 무료이며 private의 경우 분당 사용시간을 이용해서 계산한다고 한다.

알람

추가로 메일로 알람을 받도록 등록하지 않아도 문제가 생기면 등록된 메일로 해당 workflow의 결과가 날라온다.

닝겐아 실패했 다🛎

이 외 훅을 이용해서 다른 플랫폼으로 알림이 가게 하는 것도 가능하다. 이제 간략한 기능은 살펴봤고 TOAST UI Grid에 맞는 workflow를 작성해보도록 하겠다.

TOAST UI Grid workflow 만들어 보기

TOAST UI Grid는 NHN FE개발랩에서 개발하고 있는 오픈소스이다. 이제 이 글을 읽는 사람들은 TOAST UI Grid의 메인테이너가 되는 것을 상상해보자. 개발한 누군가 PR을 올렸다. 외부 컨트리뷰터일 수도 있고 FE개발랩 개발자일수도 있다. PR이 올라오거나, 올렸을 때 작업 브랜치에 머지 되기 전 코드리뷰 외 몇 가지 테스트할 일들이 존재한다. 몇 가지만 나열해보면

  1. 수정사항이 부서의 스타일 규칙을 잘 맞췄는지
  2. 작성한(혹은 작성된)테스트가 잘 통과하는지
  3. 빌드상에 문제 또한 없는지 등을 확인 할 수 있을 것 같다.
  4. 코드리뷰 등등..
체크사항을 통과하지 못했으니 머지할 수 없다!

이때 문제가 발생한다면 github의 브랜치 정책을 사용해서 merge 할 수 없게 하면 될 것이다. 현재는 이런 역할을 로컬 환경에 구축된 jenkins로 자동화하고 있다. 이런 일을 github actions가 수행하도록 간단하게 workflow를 만들어 봤다.

workflow 만들어 보기

테스트는 tui.grid를 포크한 개인 저장소에서 이뤄졌다.

설정 파일을 작성하기 위해 액션 탭을 들어가보자. 이미 쉽게 사용할 수 있도록 여러 환경들의 템플릿이 제공되고 있는 것을 확인할 수 있다.

이미 많은 환경에서 액션을 쉽게 사용할 수 있도록 설정파일들이 만들어져 있다.

여기서 사용하고 싶은 환경을 선택해서 확장하거나 직접 workflow를 만들 수 있다. 위에서 정리했던 workflow를 수행하는 일별로 조금 더 구체화해보자. 우리는 eslint 정적 분석을 해야 하며 Cypress를 테스트해야 하므로 Node.js 환경에서 작업했다.(Cypress의 경우 제공되고 있는 workflow가 존재하지만 (링크) 모노레포 문제로 제한이 있는 것 같아 node 환경에서 직접 작성했다. 이슈를 작성했으니 이후에 답변이 오면 글에 어떻게 해결하는지 작성해보겠다. 이슈 링크)

본격적으로 workflow를 작성하기 전에 구체적으로 일을 정리해보면

  1. 테스트 준비
    1. 노드 버전 선택
    2. 전체 npm install
    3.package/toast-ui.grid npm install
  2. eslint 분석
  3. cypress e2e 테스트

전체의 흐름을 workflow라 호칭하며, 위에 언급한 각각의 일을 job이다. 이 job들이 실행되는 순서는 step이라 부르게 된다. 그럼 workflow를 작성해보자. 만드는 것은 어렵지 않다. .github/workflows/ 경로에 yml 파일을 만들면 된다. (설정파일을 만드는 것은 에디터에서 작성해도 괜찮지만, 개인적으로는 포맷팅자동완성을 제공하기 떄문에 github 웹상에서 작성하는 것을 추천한다.)

그럼 작성한 yml 파일의 주석을 살펴보면서 용어를 확인해보자.

cypress가 18.04 ubuntu 환경에서 xvfb issue가 있어 16.04에서 테스트 했다.
* 링크1: https://help.github.com/en/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstepsif

테스트하기

그럼 작성한 workflow가 정상 작동하는지 테스트해보자. 두 워크플로 과정에서 각각 문제가 발생하도록 예제를 만들어보자. 먼저 eslint 룰에 위배되는 코드를 작성해서 PR을 올려봤다.

개행을 시켜 빨간줄이 나타나게 했다.

해당 내용을 푸시해서 PR을 만들었고 올리자 마자 actions이 실행 된 것을 볼 수 있었다. Detail에 들어가보면

eslint에 ❌

eslint를 돌렸을 때와 동일하게 어느 부분에서 문제가 발생했는지 액션상에서 확인해 볼 수 있었다. 그럼 다음으로 eslint 문제가 생긴 부분을 해결하고 cypress 테스트를 일부러 수정해서 테스트가 깨지도록 해보자. column.spec.ts의 결과 값을 살짝 바꿔서 PR을 올려봤다.

test에 ❌

eslint는 통과했지만 column.spec.ts가 통과하지 못해 해당 workflow를 통과하지 못했다. 각각 원하는 부분에서 빨간불을 띄워봤다. 간단하게 하나의 workflow를 만들어 봤다. 젠킨스를 구성하지 않고 몇 가지 커맨드로 해당 일들을 빠르게 해결할 수 있었다. 하지만 안정적이지 못한 면도 아직 존재했다.

안정적이지 못한 점이라고?

matrix로 여러 환경에서 테스트를 병렬적으로 할 수 있다고 해서 cypress를 돌려봤는데 전부 다른 환경에서 테스트가 실패하였다. 이유를 모르게 갑자기 중단된 테스트도 있었고 정상적으로 통과했어야 하는 테스트가 실패하는 경우도 있었다.(병렬로 수행했을 때 발생하는 이슈로 파악된다. 각각 테스트를 수행하면 전부 통과하겠지만 이 경우에는 큰 의미가 없는 부분이다.)

모두 통과했어야 하는 테스트다ㅠㅠ

각각의 노드 버전을 명시해 테스트 했을 경우 통과했지만 간헐적으로 테스트가 실패하였다. 같은 코드이지만 다르게 실패하는 부분에서 원인을 파악하기 어려웠고 지속적으로 현상이 지속될 경우 통과된 테스트가 신뢰있는 결과일지에 대해서는 다시 생각해야 할 것 같았다.(원인을 이후에 파악한다면 댓글로 남겨놓도록 하겠다. grid 테스트 코드 문제일 수도 있다️🤦‍♂️)

결론

FE개발랩은 우선으로 TOAST UI Grid에 Github actions을 도입할 예정이며 위 workflow 뿐만 아니라 여러 배포과정에서 발생하는 작업들을 actions로 자동화할 예정이다. 💪 이미 크고 많은 오픈소스에서 도입하여 사용하고 있다. 피드백 또한 빠르게 반영되고 있고 큰 CI 회사나 테스트 도구들도 github action상에서 작동할 수 있게 개발하거나 이미 출시한 경우가 대다수다.

현재 TOAST UI의 컴포넌트 들은 셀레니움 등 여러 이유로 사내 환경에 jenkins를 구축하여 폴링하여 workflow를 수행하고 있다. 추가적인 관리 이슈 또한 부담스러워지고 있다. 이후에 여러 private 환경에서 구축된 CI 혹은 깃헙 엔터프라이즈 환경에서도 깃헙 액션을 지원한다고 하니 계속 지켜볼 만하다고 생각한다. (깃헙 액션을 통한 부동산 알림 글처럼 scheduler를 이용하면 단순히 CI 용도를 넘어서 재밌는 목적으로도 많이 사용할 수 있을 것 같다.)

부록

Action은 아니지만 DeepScan

  • https://deepscan.io/dashboard/
  • 코드 상에 사용되지 않는 코드들이나 잘못된 문법을 파악해서 알려준다.
  • 아직 타입스크립트가 완벽하게 지원되는 느낌은 아니다.
  • 하지만, 사람이 놓칠 수 있는 부분들을 찾는 데 도움을 줄 수 있다고 생각한다.

github actions에서 npm node_modules 캐싱 사용하기

--

--

Jung Han
Jung-han

개인용 블로그로 사용하고 있습니다. 좋은 개발자가 꿈입니다. > https://www.notion.so/Han-Jung-c43f4bcd2b3f4b3d85b93aee41c5e098