Github Actions란

깃허브에서 제공하는 CI / CD 를 위한 서비스

 

GItHub Actions를 사용하면 자동으로 코드 저장소에서 어떤 이벤트 발생시 특정 작업이 일어나게 해주거나 주기적으로 어떤 작업들을 반복해서 실행시킬 수 있음.

 

ex)

누군가 PR을 생성하면 GitHub Actions를 통해 해당 코드에 문제가 없는지 각종 검사 진행이 가능.

 

새로운 코드 변경 사항이 기본 브랜치 (mastser or main)에 push 되면 GitHub Actions를 통해 sw를 빌드하고 상용서버에 배포(deploy) 할 수 있음.

 

매일 밤 특정 시각에 그날 하루에 대한 통계 데이터를 수집 시킬 수도 있음. 

 

---

소프트웨어에서 지속적으로 수행해야하는 반복 작업들은 CI/CD로 불림.

 

사람이 직접 하기에 비효율적이고 실수할 위험 때문에 자동화시키는 것이 유리.

 

예전에는 CI/CD가 DevOps 엔지니어들의 전유물이었다면 최근에는 GitHub Actions를 통해 일반 개발자들도 CI/CD 설정을 스스로 할 수 있음.

 

 

---

GitHub Actions를 사용하기 전 숙지하면 도움이 되는 개념들

 

Workflows

Workflows란? ) GItHub Actions에서 가장 상위 개념이며 자동화 해놓은 작업 과정이라고 볼 수 있음.

 

  - 워크 플로우는 코드 저장소 내에서 /github/workflows 폴더 아레에 YAML 파일로 설정.

 

  - 하나의 코드 저장소 내에는 여러 개의 워크 플로우 (== 여러개의 YAML 파일) 생성 가능.

 

 

워크 플로우 YAML 파일에 정의해야하는 2가지 ) on , jobs

 

  1. on 속성을 통해 해당 워크 플로우가 언제 실행되는 지를 정의

 

   ex) 코드 저장소의 main 브랜치에 push 이벤트가 발새할 때마다 워크플로우를 실행해야한다면

 

.github/workflows/example.yml

on:
   push:
      branches: [main]

jobs: //생략

 

매일 자정에 워크 플로우를 실행하려면

on:
   schedule:
      - cron: "0 0 * * *"

jobs:
  //생략

 

 

2.  jobs 속성을 통해 해당 워크플로우가 구체적으로 어떤 일을 해야하는지 명시.

  아래에서 서술

 

---

Jobs

Jobs란? ) GitHub Actions에서 작업(Job)이란 독립된 가상 머신(machine) 또는 컨테이너(container) 에서 돌아가는 하나의 처리 단위 의미.

 

  - 하나의 워크 플로우는 여러 개의 작업으로 구성되며 적어도 하나의 작업이 있어야 함.

   (Jobs가 하나도 없으면 실행할 작업이 없으니 워크플로우 의미가 없음!)

 

  - 모든 작업은 기본적으로 동시에 실행되며 필요 시 작업 간에 의존 관계를 설정하여 작업이 실행되는 순서를 제어할 수도 있음.

 

작업은 워크플로우 YAML 파일 내에서 jobs 속성을 사용하여 작업 식별자(ID)와 작업 세부 내용 간의 매핑(mapping) 형태로 명시.

 

 

ex) job1, job2, job3 이라는 작업 ID를 가진 3개의 작업을 추가

// 생략

jobs:
   job1:
      // job1에 대한 세부 내용
   job2:
      // job2에 대한 세부 내용
   job3:
      // job3에 대한 세부 내용

 

작업의 세부 내용으로는 여러 가지 내용을 명시할 수 있음.

 

필수로 들어가야하는 runs-on 속성을 통해 리눅스나 윈도우즈와 같은 실행환경을 지정해줘야 함.

 

ex) 우분투의 최신 실행환경에서 해당 작업을 실행하고 싶다면

// 생략

jobs:
   job1:
      runs-on: ubuntu-latest
      steps:
        //생략

 

작업에서 가장 중요한 것은 작업 순서를 정의하는 것. steps 속성을 통해 설정

---

Steps

Steps란? ) 하나의 작업은 일반적으로 여러 단계의 명령을 순차적으로 실행하게 됨.

  GitHubActions에서는 각 작업(job)이 하나 이상의 단계(step)로 모델링 됨.

 

  - 작업 단계는 단순한 커맨드나 스크립트가 될 수 있고 액션이라는 복잡한 명령일 수도 있음.

 

  - 커맨드나 스크립트를 실행할 때는 run,   액션을 사용할 때는 uses 속성을 사용

 

ex) 자바스크립트 프로젝트에서 테스트를 돌리려면 

    1. 코드 저장소에 코드를 작업 실행 환경으로 내려받고

    2. 패키지를 설치한 후

    3. 테스트 스크립트를 실행

//생략

jobs:
   test:
      runs-on: ubuntu-latest
      steps:
         - uses: actions/checkout@v3
         - run: npm install
         - run: npm test

 

워크 플로우 파일 내에서 작업 단계를 명시해 줄 때는

YAML 문법내에서 시퀀스타입을 사용하기 때문에 각 단계 앞에 반드시 - 를 붙여야 함.

 

---

Actions

Actions란? ) GitHub Actions에서 빈번하게 필요한 반복 단계를 재사용하기 용이하도록 제공되는 일종의 작업 공유 매커니즘. 

 

  - 이 액션은 하나의 코드 저장소 범위 내에서 여러 워크 플로우 간에서 공유할 수 있고, 

    공개 코드 저장소를 통해 액션을 공유하면 GitHub 상의 모든 코드 저장소에서 사용이 가능해짐.

 

  - GitHub에서 제공하는 대표적인 공개 액션으로는 체크 아웃 액션(actions/checkout)이 있음.

 

   -> 대부분의 CI/CD 작업은 코드 저장소로부터 코드를 작업 실행환경으로 내려받는 것에서 시작하므로 이 액션이 범용적으로 사용됨.

 

---

정리

깃허브 액션은 특정 이벤트가 발생했을 때 특정 작업을 실행할 수 있고,
주기적으로 특정 작업을 실행하게 할 수 있어 CI/CD 작업에 이용될 수 있다.

깃허브 액션을 이용하기 위해서는 YAML 파일에 워크플로우를 정의해줘야 한다.

* 워크 플로우 파일은 꼭 ! .github/workflows 폴더 아래에 YAML파일로 위치해야함 !

워크플로우(==YAML)은 여러 개를 만들 수 있으며
워크플로우에는 on과 jobs이 필수로 정의되어야 한다.

on : 해당 워크플로우가 언제 실행되는지 정의. 
  ex) main 브랜치에 push 이벤트가 발생할 때마다 워크플로우 실행

jobs : 최소 한 개이상의 jobs가 있어야 하며 on으로 워크플로우가 실행됐을 때 어떤 작업을 할지 정의.
  각 작업에는 작업 ID가 부여되고 세부 내용이 명시된다.
  필수로 들어가야하는 runs-on 속성을 통해 리눅스나 윈도우즈와 같은 실행환경을 지정

steps : 작업 간의 순서를 명시. 각 단계는 단순한 커맨드 일 수도, 추상화된 액션일 수도 있음
  커맨드나 스크립트를 실행할 때는 run, 액션을 사용할 때는 uses 속성을 사용.
  작업단계를 명시할 때는 각 단계 앞에 반드시 - 를 붙여야 함.

actions : 빈번하게 필요한 반복단계를 재사용하기 용이하도록 제공되는 작업 공유 매커니즘.
  대표적인 공개 액션으로는 actions/checkout이 있음.
   (코드 저장소로부터 코드를 작업 실행 환경으로 내려 받는 것)

 

다음 포스팅에서는 내 갠플에 적용해보겠다 !

---

모든 내용은 아래 블로그 들에서 참고했습니다.

 

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

GitHub Actions의 소개와 핵심 개념