[CI] Github Actions CI 적용하기 #1 - Github Action 살펴보기

이전 포스트에서 CI와 CD가 어떤 상황에서 사용되는지에 대해 알아보았다. 이번에는 CI(Continuous Integration)를 구현해 볼 것이다. 현재 초기 개발단계인 프로젝트는 dev 브랜치에 병합을 하면 Development 서버에 배포가 된다. 이 레포지토리에 아래 규칙을 강제해 볼 것이다.

dev 브랜치에 Pull Request를 하면 Unit Test를 통과해야만 Merge가 가능하다. 

 

우선 이 규칙을 만들기 위해서는 Github Actions 를 사용해야한다.(한글문서를 제공하니 참고하자). 우선 필자가 작성한 스크립트를 보기 전에 해당 글에서는 Github Action에 대해 간단히 짚고 넘어가보자. 문서에서 제공하는 대표 예시를 기준으로 기본적인 Github Action에 대한 이해와Github Action필드의 Warm up을 진행해보자.

 

Github Action 단위 짚고가기

문서

Understanding GitHub Actions - GitHub Docs

Workflow

Workflow는 하나 이상의 job을 실행시키는 단위이다. Workflow는 yaml 형식의 파일에 정의된다. 레포지토리에서 정의된 이벤트에 따라 트리거가 발동되거나 스케줄링이 이루어지게 된다. Workflow는 레포지토리 root 디렉토리 기준, .github/workflow 라는 디렉토리에 정의된다. Workflow는 하나 이상의 Multiple Workflow를 가질 수 있으며, 서로 다른 Task를 가질 수 있다.

 

Jobs

문서

Job이라는 단위는 Workflow라는 집합 단위를 이루고 있는 요소이며 동일한 Runner에서 실행되는 단위들이다. Job은 step이라는 단위들로 이루어져 있다. step은 순차적으로 실행되며 상호 의존적인 성격이 있다(이전 step은 다음 step에 영향을 미친다는 의미이다.) 각각의 Step들은 데이터가 공유되는 성격을 띄고 있다. 조금 쉽게 생각하면, 현재 step에서 프로젝트 컴파일을 하고 난 후, 다음 step은 컴파일한 결과를 활용할 수 있는것이다.

 

기본적으로 Job들은 모두 병렬적인 처리로 실행된다. 하지만 Job들간의 의존성 설정을 통해 실행 순서를 순차적인 형태로 변경해줄 수 도있다. 틀린 예시일 수 도 있지만, 예를들어 Mono Repo 프로젝트에 대해 Job을 설정한다 가정하면 병렬적인 처리와 순차적인 처리 두가지 모두 쓰이는 경우에 대해 예를 들 수 있다.

 

• 병렬적인 처리: Backend코드에 대해 빌드를 진행하고, Frontend와 CSS(tailwind와 같은)컴파일, 우선 이 두가지 작업이 필요하다. 이 두가지 Job은 서로 의존성이 없기때문에 병렬적인 처리를 해도 괜찮다.
• 순차적인 처리: 위 Backend와 Frontend 빌드가 완료되고, 각각의 빌드/컴파일 결과에 대해 테스트를 진행한다고 가정하면, "테스트"라는 과정은 결국 빌드/컴파일 단계에 의존하기 때문에 순차적인 처리로 변경해 주어야 한다.

Job간의 데이터 공유는 Github Actions의 download/upload-artifact 를 사용하면 된다.

- Download Artifact: https://github.com/actions/download-artifact
- Upload Artifact: https://github.com/actions/upload-artifact

 

Actions

문서

Actions는 복잡하고 반복적인 Task를 줄일 때 사용한다. Action은 Github에서 기본 제공하는것을 사용하거나 Third-Party Action을 Marketplace로 부터 사용할 수 있다. 또한 필요에 따라 Action을 직접 제작할 수 도 있다. 

Create Github Action: https://docs.github.com/en/actions/creating-actions

 

 

Runners

문서

Runner는 Workflow가 실행되는 서버 환경에 대한 정의이다. Github는 Ubuntu, Windows, MacOS등의 운영체제를 제공해준다. 또한 필요에 따라 Runner를 Self Hosting할 수 도 있다.

 

Document 예시 살펴보기

name: learn-github-actions
run-name: ${{ github.actor }} is learning GitHub Actions
on: [push]
jobs:
  check-bats-version:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v3
        with:
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v

 

name

Optional 필드이다. Github Action에서 보여질 Action의 이름이다. 만약 값이 누락된다면, Workflow 파일 이름으로 대체된다. 

 

run-name

실질적인 Workflow가 실행될때 Repository Actions 탭에서 Flow에 표기가 되는 이름이다. name 필드와의 단위가 헷갈릴 수 도 있다. 필자가 작성한 스크립트의 name, run-name필드와 Actions탭에서 표기되는것을 비교해서 살펴보자

 

 

파란 부분이 name 필드, 빨간 부분이 run-name 필드를 의미한다.

on

on 필드는 workflow가 trigger되는 상황에 대한 세부정의이다. 해당 예시에서는 push 이벤트가 발생하는 경우에만 해당 workflow가 trigger되도록 한 것이다. Workflow가 Trigger되는 이벤트들의 목록은 해당 문서를 참조하자. 이벤트의 경우에는 하나 혹은 하나 이상이 될 수 있다. 이벤트가 Trigger되는 브랜치에 대한 제한도 여기서 진행한다.

 

https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#onevent_nametypes

Workflow syntax for GitHub Actions - GitHub Docs

 

https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#available-events

Events that trigger workflows - GitHub Docs

 

jobs

위에서 보았던 Job 단위에 해당한다. jobs 필드의 경우, 해당 workflow에서 실행할 모든 job들을 모아두는 yaml array 타입이다. 여기서는 "check-bats-version" 라는 하나의 Job만 존재한다.

 

jobs.<job_id>.runs-on

위에서 보았던 Runners 단위에 해당한다. Job이 실행될 환경에 대한 정의를 진행해준다. 세부적으로 설정할 수 있는 Runners 스펙들은 아래 문서를 참조하자.

 

https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#choosing-github-hosted-runners

Workflow syntax for GitHub Actions - GitHub Docs

 

jobs.<job_id>.steps

Job을 이루는 step들이다. 여기서는 위에서 보았던 Actions 단위도 활용된다.  예시를 보면 uses, run 키워드로 이루어져있는것을 볼 수 있다. uses 키워드는 사전 정의된 Actions를 사용할때 작성한다. 위에서는 총 두가지의 Actions를 사용한것을 볼 수 있다. Github Action에서 제공하는 공식 Action 혹은 Third Party Action들은 모두 사용법이 다르므로 (With에 정의해줘야하는 Property등) 문서를 참고하면서 진행해야한다.

 

• actions/checkout@v4: Workflow가 실행되는 브랜치의 코드를 가져올 때 사용(기본값)한다. 다른 브랜치의 코드를 불러올 수 도 있다. 
  • https://github.com/actions/checkout

GitHub - actions/checkout: Action for checking out a repo

• actions/setup-node@v3: Node.js Runtime 실행환경을 준비해준다. Runners는 운영체제만 제공해주므로, Runtime을 Action으로 실행해주어야한다. Node.js 뿐만 아니라 다른 Runtime, 프로그래밍 언어도 제공된다. 제공되는 Runtime  버전이있기때문에,문서를 보면서 조절해 주어야한다. 위 예시에서는 버전 14가 사용된것을 볼 수 있다.
  • https://github.com/actions/setup-node

GitHub - actions/checkout: Action for checking out a repo

 

Step과 Step에 대한 세부 필드에 대한 문서는 아래를 참고하자.

https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idsteps

Workflow syntax for GitHub Actions - GitHub Docs