이번에 CI/CD를 위해서 외부툴이 아닌 github에서 제공하는 Github action을 사용해 보고자 이렇게 포스팅을 정리해본다.
Github actions 구성요소를 이해할 필요가 있다.
github acstions에서 사용되는 yaml파일 내 기본적인 구성요소는 workflow, event, runner, jobs, steps, actions 로 볼 수 있다.
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@v3 #액션
- uses: actions/setup-node@v3
with:
node-version: '14'
- run: npm install -g bats
- run: bats -v
workflow는 레포지토리에 추가할 수 있는 일련의 자동화된 커맨드 집합을 말한다.
보통 하나의 yaml파일이 하나의 워크플로우가 될 수 있다.
workflow의 하나의 event 트리거와 하나 이상의 job으로 이루어 져있으며, .github/workflows 디렉토리에 yaml파일로 저장된다.
event는 Workflow를 실행시키는 Push, Pull Request, Commit 등의 특정 행동을 의미한다.
workflow를 실행시키는 방아쇠가 되기 때문에 event Trigger 또는 workflow Trigger라고도 부른다.
예를 들어 리포지토리의 기본 브랜치에 대한 푸시가 이루어지거나 릴리스가 생성되거나 이슈가 열릴 때 실행되도록 워크플로를 구성할 수 있다.
runner는 GitHub Actions 워크플로우를 실제로 실행하는 서버를 의미한다.
Job을 실행시키기 위한 애플리케이션이라고도 생각할 수 있다. Ubuntu, Windows, macOS 환경의 러너를 선택해서 동작시킬 수 있는데 위의 yaml파일의 runs-on에 해당하는 OS환경을 runner라고 생각할 수 있겠다.
Job은 동일한 Runner에서 실행되는 여러 Step의 집합을 의미한다. 이는 워크플로우를 구성하는 실행 단위로 볼 수 있으며,
기본적으로 워크플로우내의 모든 작업은 병렬로 실행된다.
필요에 따라 의존 관계를 설정하여 순서를 지정해줄 수 있다.
Step은 커맨드를 실행할 수 있는 각각의 Task를 의미하는데, Shell 커맨드가 될 수도 있고, 하나의 Action이 될 수도 있다.
작업 내의 step들은 순차적으로 실행되며, 하나의 Job 내에서 각각의 Step은 동일한 러너(Runner)에서 실행되므로 상호 데이터를 공유할 수 있다.
Action은 Job을 만들기 위해 Step을 결합한 독립적인 커맨드로, 재사용이 가능한 Workflow의 가장 작은 단위의 블럭이다.
Github Marketplace에 생성된 Action을 불러와 사용할 수 있으며, 다른 사용자들이 자신의 워크플로우에 다른 사람들이 만든 액션을 가져와 사용할 수 있다.