[CI/CD] Github Actions 기본개념과 사용법 정리

Github Actions

Github Actions는 Microsoft에서 Github을 인수한 뒤 출시된 CI 솔루션이다. Github과 연동하여 PR 이벤트뿐만 아니라 다양한 이벤트에 trigger 될 수 있는 다양한 작업을 정의할 수 있다. 또한 다양한 action들이 마켓플레이스에 공개되어 있어서 쉽게 workflow를 작성할 수 있다는 점과 CI 서버를 따로 설치하지 않고도 Github에서 제공하는 클라우드 호스팅을 통해 빠르게 CI파이프라인을 구축할 수 있다는 장점이 있다. 이번 포스팅에서는 Github Actions에 대해 넓고 얕게 핵심 개념과 기본 사용법에 대해 작성했다.

 

 

Github Actions 주요 개념 5개

Github Actions을 사용하기 전에 알아야 할 주요 키워드는 총 5개이다.

 

github actions의 core 개념 도식화

 

1. workflow

- 특정 event가 발생했을 때, 수행할 일을 정의하는 것을 의미한다. 즉, 각 event에 대한 프로세스를 의미한다.

- workflow는 yaml 파일로 작성되며 github 레포지토리의 .github/workflows 디렉토리 아래 저장한다.

- workflow는 1개 이상의 Job으로 구성된다.

 

2. event

- workflow를 트리거하는 특정 이벤트

- 대표적인 예로 특정 브랜치에 Push되는 이벤트, PR 이벤트, 스케줄링, issue open 등이 해당한다.

cf. 이벤트 종류

branch_protection_rule 

check_run 

check_suite 

create 

delete 

discussion 

discussion_comment 

deployment_status 

deployment 

fork 

gollum 

issue_comment 

issues 

label 

merge_group 

milestone page_build 

project_card 

project_column 

project 

public 

pull_request_review_comment 

pull_request_review 

pull_request 

push 

registry_package 

release 

repository_dispatch 

status 

watch 

workflow_dispatch 

workflow_run 

schedule 

pull_request_target

 

3. job

- job은 여러 개의 step으로 구성되며 Github Actions의 클라우드 서버에서 실행된다.

- job 단위로 CI서버의 독립적인 VM 또는 컨테이너에서 실행된다.

- 다른 job과의 의존관계를 갖도록 만들 수도 있으며 그렇지 않은 job들은 병렬적으로 실행된다.

- 정적분석, 단위 테스트, 빌드 등 다양한 job을 정의할 수 있다.

 

4. step

 

- 위 사진은 step을 정의한 일부이다.

- 각 Job은 여러 개의 step으로 구성되며 step들은 순차적으로 실행된다.

- step은 단순 커맨드나 Script, action 형태로 정의할 수 있다. 

 

5. actions **

- 위 사진은 step을 정의한 일부이다. action은 step에 정의해서 사용한다.

- actions란, 깃헙에서 미리 정의해둔 작업으로, 공개적으로 오픈된 마켓플레이스에서 액션들을 사용할 수 있다. 

- 마켓플레이스에는 수많은 벤더가 공개해놓은 다양한 action을 쉽게 접할 수가 있다. 한 마디로 이 액션을 중심으로 하나의 큰 커뮤니티가 형성이 되고 더 많은 사용자와 벤더가 GitHub Actions으로 몰려드는 선순환이 일어나고 있는 것이다.

- 재사용이 가능한 컴포넌트로 job을 만들기 위해 step들을 연결한다.

 

6. runner

- runner는 Job을 실행시키는 주체이며, 각 Job들은 독립적인 runner(container)에서 실행된다.

- runner는 VM 머신 또는 컨테이너로 생각하면 된다.

- Github에서 호스팅해주는 Github-hosted runner와 직접 호스팅하는 Self-hosted runner가 있다.

- Github-hosted runner는 Azure의 vCPU 2, 메모리 7GB, 스토리지 14GB를 제공하며 이는 추후 변동될 수 있다.

 

 

https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners

 

위 사진은 현시점에서 제공되는 Github-hosted runner 스펙이다. Windows, Linux, macOS가 제공된다.

 

---

yml 파일 구조

프로젝트의 최상위 경로에 .github/workflows/ 디렉토리를 생성하고 yml 파일을 만든다. 

 

 

 

* env 키워드로 환경변수를 설정하면 step 영역에서 자유롭게 사용할 수 있다. 이때 $ 기호를 환경변수에 붙여 사용한다.

* run 오퍼레이션을 통해 커맨드를 전달할 수 있다. 만약 스크립트 파일을 따로 두고 이 스크립트 파일을 실행할 경우, 스크립트 파일 내에서 에러가 발생한 경우를 잡아주지 못한다. 따라서 actions의 성공, 실패 여부를 판별하기 위해 스크립트 파일은 지양하는 것이 좋다.

 

 

cf. chckout action : workflow에서 레포지토리에 있는 코드에 접근하기 위해 check-out하는 action이다. 즉, 코드 저장소로 부터 코드를 작업 실행 환경으로 내려받기 위해 사용되는 action이다. 보통 CI/CD는 코드를 내려받는 것으로부터 시작하기 때문에 거의 모든 Github Action프로젝트에서 checkout action을 사용할 것이다. 모든 브랜치로부터 history를 가져오기 위해서는 fetch-depth: 0 를 설정하면 된다. checkout action을 활용하면 다른 레포지토리에서 코드를 가져오든지 특정 브랜치에서 코드를 가져오는 작업 등 내려받을 코드의 위치를 명시하여 활용할 수도 있다. 자세한 정보는 링크를 참고하시기 바랍니다.

 

 

---

 

* 참고 *

스케줄링 이벤트 예시 (schedule)

  on:
    schedule:
      - cron: '0 0 * * *'

event에 cron식을 기반으로 스케줄링을 등록할 수도 있다. 

 

 

Job 간의 의존관계 설정 예시 (needs)

  jobs:
    job1:
    job2:
      needs: job1
    job3:
      needs: [job1, job2]

needs 키워드를 사용하면 Job 들을 병렬로 실행하지 않고 순차적으로 실행시킬 수 있다. 공식문서 참고

 

 

산출물, 로그 기록 관리

레포지토리 설정에서 Actions -> General에서 다음과 같이 Artifact와 로그 기록 기간을 설정할 수 있다.

 

 

 

이 외, 다양한 예제는 링크를 참고하시기 바랍니다.

 

 

 

 

 

Reference

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

- https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners

- https://www.daleseo.com/github-actions-basics/

- https://devblog.kakaostyle.com/ko/2020-11-06-1-using-github-actions/