Overview
GitHub Action은 빌드, 테스트 그리고 배포에 관한 pipeline을 자동화해주는 CI/CD 플랫폼 이다.
repo에 대한 모든 Pull Request(이하 PR)를 빌드, 테스트 그리고 production에 merge 해서 배포하는 workflow를 생성할 수 있다.
GitHub Action은 단순한 DevOps를 넘어서 repo에 어떤 event가 발생하면 workflow를 실행할 수 있게 해준다. 예를 들어, 누군가 새로운 issue 를 등록 했을 때 적절한 label을 자동으로 추가해주는 workflow 를 실행할 수 있다.
GitHub Action의 구성
repo에 발생하는 pull request 나 issue 생성과 같은 event를 트리거로 동작하는 Gtihub Action workflow 를 구성할 수 있고, 해당 workflow는 순차적이나 병렬적으로 동작 할 수 있다. 각각 읜 job은 virtual machine runner 나 container 내부에서 실행되고 하나 이상의 script나 action을 수행한다.
workflows
workflow는 하나 이상의 job 으로 구성 가능한 자동화된 프로세스 이다. workflow는 YAML 파일로 정의 되어 있으며, repo에서 일어나는 event나 수동으로 트리거 되거나 정의된 스케쥴에 의해 체크되어 동작한다.
Repo에는 다른 step의 set으로 동작하는 복수의 workflow가 존재할 수 있다. 예를 들어, 하나의 workflow는 PR에 대해서 빌드하고 테스트, 다른 하나는 release가 생성되면 application을 deploy 하고, 또 다른 하나는 누군가 issue를 등록하면 label을 추가하는 workflow를 만들 수 있다.
workflow에서 다른 workflow의 재사용도 가능하다.
Events
Event는 workflow 수행을 트리거하는 특정한 동작이다. 예를 들어, 누군가가 pull request를 생성하거나 issue를 등록하거나 commit을 push 하는 것 들이다. 이외에도 스케쥴을 등록하거나 Rest Api 혹은 수동으로 workflow를 동작 시킬 수 있다.
Jobs
job은 workflow 안에서 동일한 runner에서 실행되는 step들의 set이다. 각 step들은 script 나 action 이다. step은 순차적으로 수행되고 다른 step과는 독립적이다. step은 같은 runner에서 수행되기 때문에 데이터를 공유할 수 있다. 예를 들어, 빌드 될 application 을 테스트해서 빌드하는 step 을 만들 수 있다.
job에 의존성을 부여할 수 있다. 기본적으로 job들은 독립적이고 다른 job에 대해서 평행하게 동작한다. 하나의 job이 다른 job에 대해서 의존성을 갖게 되면 해당 job이 완료될 때 까지 기다린다. 예를 들어, 다른 아키텍처에 대해 의존성이 없는 multiple 빌드가 있고, 다른 job에 의존되어 있는 packaging job이 있다. multiple 빌드가 병렬적으로 수행되고, 모든 빌드가 성공적으로 완료 되었을 때, packaging job이 수행 된다.
Actions
복잡하지만 자주 반복되는 task를 수행하는 custom application 이다. workflow 파일에 작성해서 반복되는 코드를 줄일 수 있다. action은 repo를 pull 해서 알맞은 toolchain 을 지정하거나 cloud 제공자의 authentication 을 설정 할 수 있다.
Action 을 작성할 수도 있고, GtiHub Marketplace 에서 workflow 에 사용할 action을 찾을 수도 있다.
Runner
workflow 가 트리거 되었을 때 동작할 서버이다. 각 runner 는 한번에 하나의 job을 수행한다. GitHub는 Ubuntu Linux, Windows, macOS 를 지원한다. 각 workflow는 새로 생성된 virtual machine 에서 동작한다. 만약 특정한 OS나 하드웨어 환경을 원한다면 스스로 runner 를 호스트 할 수 있다.
Create an example workflow
GitHub Actions는 workflow정의를 위해 YAML을 사용한다. 각 workflow는 .github/workflows/ repo에 분리된 YAML파일로 저장된다. (.yaml 파일은 .yml 확장자를 사용하는 경우가 더 많다)
name: learn-github-actions
on: [push]
jobs:
check-bats-version:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions/setup-node@v2
with:
node-version: '14'
- run: npm install -g bats
- run: bats -v위의 코드를 .github/workflows/ 폴더를 생성해서 learn-github-actions.yml 파일로 생성한다.
Understanding the workflow file
| workflow syntax | description |
|---|---|
| name: learn-github-actions | optional Github repo의 action tab에 나타나는 workflow의 이름이다. |
| on: [push] | 해당 workflow의 지정된 트리거이다. 해당 workflow에서는 push 이벤트가 발생하면 동작한다. 해당 workflow는 모든 브런치에서 트리거 된다. 만약 특정 브런치 에서만 트리거 되기를 원한다면 paths나 tag를 지정해 줄 수 있다. |
| jobs: | 해당 workflow에서 동작되는 모든 job 이 모여있다. |
| check-bats-version: | job의 이름을 check-bats-version 로 정의한다. child keys 는 job의 특징을 정의할 것 이다. |
| runs-on: ubuntu-latest | runner를 ubuntu 최신 버전으로 지정한다. |
| steps: | check-bats-version job에서 동작하는 모든 step 이 모여있다. 각 item 들은 해당 steps 아래 분리된 action이나 script로 중첩된다. |
| uses: actions/checkout@v2 | uses 는 run에서 수행할 action을 지정한다. v2버전의 actions/checkout을 수행한다. repo의 code를 불러온다. |
| - uses: actions/setup-node@v2 with: node-version: '14' | node 14버전을 사용한다. |
| - run: npm install -g bats | run 은 runner에서 수행할 command를 job에게 전달한다. 해당 커맨드로는 bats를 설치한다. |
| - run: bats -v | bats의 버전을 확인한다. |
Visualizing the workflow file
!
step 1, 2는 action의 실행이고, step 3, 4 는 script의 수행이다.
Viewing the workflow's activity
- Github.com 의 repo에 접속
- repo의 이름 아래 Actions 탭을 클릭
- 왼쪽의 sidebar에서 보고싶은 workflow를 클릭
- "workflow runs" 아래에서 보고싶은 run의 이름을 클릭.
- Jobs나 그래프 에서 보고싶은 job을 클릭
- 각 step의 결과를 확인한다.
Reference
