Git Actions A to Z

Intro

프로젝트에서 자동화 파이프라인을 구성하는 도중 여러 환경에서 기능 테스트를 진행해보고, 프로덕션 환경에서 통합 테스트를 진행해 보기 위해 Git Actions을 학습했습니다.

파이프라인은 AWS 문서를 참고했습니다.

Git Actions 이란?

대표적인 빌드, 테스트 및 배포 파이프라인을 자동화를 도와주는 CI&CD 플랫폼이며 이벤트 기반으로 설정한 명령을 수행합니다.

Git Actions 구조

그림으로 보는 Git Actions 구조

Git Actions은 이벤트가 발생하면 트리거되도록 Workflow를 구성합니다. 전체적인 구조는 다음과 같습니다.

Git Actions의 구조로 이야기를 하자면 우리가 원하는 작업을 작성한 파일이 Workflow가 되고, Workflow를 어떤 시점에 실행할지 설정하는 부분은 Events, Workflow가 실행할 작업 단위를 Job이라 합니다.

문서에서 볼 수 있는 Git Actions 구조

Git Docs에 있는 그림으로 정리하면 다음과 같습니다.

구성

• Workflow에는 하나 이상의 Job이 있다.
• Job에는 하나 이상의 Step이 있다.
• Job은 자체 Runner(가상 머신 또는 컨테이너) 내에서 실행된다.

특징

• 실행하기 위해 작성된 스크립트는 Step 단위 관리되며 Job에 포함된다.
• Job은 Workflow에 포함되며 순차적이거나 병렬로 실행된다.
• Job은 자체 가상 머신 단위인 Runner 내에서 실행된다.

코드로 보는 Git Actions 구조

그럼 깃 허브에서 제공해주는 템플릿 코드로 보면 쉽게 이해할 수 있습니다.
on 뒤에는 여러 개의 Event를 설정할 수 있기 때문에 Events라는 복수형을 사용하게 됩니다. Jobs도 마찬가지로 여러 개의 Job으로 구성되기 때문에 복수형을 사용하고 있습니다.

여러 개의 Event 구성

여러 개의 Event를 구성하는 방법은 다음과 같습니다.

여러 개의 Job 구성

여러 개의 Job을 구성하는 방법은 다음과 같습니다.

Events, Job 를 알아보자

Events - 어떤 상황에서 실행하고 싶은지

Workflow에서 Events를 이용해 원하는 상황에서 Jobs를 실행할 수 있습니다. Event는 크게 github에서 제공하는 Event와 특정 엔드포인트를 사용한 Event가 있습니다.

Github에서 제공하는 Event

Github에서 제공하는 Event는 정말 많기 때문에 일부분만 가져왔습니다.

해당 문서에서 모든 이벤트를 확인할 수 있습니다.

Event 등록방법은 다음과 같습니다.

on: push

두 개 이상을 등록하는 경우 다음과 같이 등록할 수있습니다.

on: [push, fork]

아래와 같이 특정 상황의 Event 를 지정할 수 있으니 이러한 부분을 잘 활용해 자동화를 구성할 수 있습니다.

on:
  label:
    types:
      - created

특정 엔드포인트에서 사용하는 경우

특정 엔드포인트를 사용하여 GitHub 외부에서 발생하는 활동이 GitHub 작업 워크플로 또는 GitHub 앱 웹훅을 트리거할 수 있습니다.

curl -L \
  -X POST \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>"\
  -H "X-GitHub-Api-Version: 2022-11-28" \
  https://api.github.com/repos/OWNER/REPO/dispatches \
  -d '{"event_type":"on-demand-test","client_payload":{"unit":false,"integration":true}}'

저는 엔드포인트로 요청할 상황이 없기 때문에 읽기만 했습니다. 만약 필요하다면 문서를 읽어서 커스터마이징하면 됩니다.

Event를 트리거하는 방법은 다양합니다. 현재 상황에 맞게 Event를 작성하여 고도화된 자동화를 이룰 수 있으니 한 번쯤은 이해하고 넘어가는 걸 추천드립니다.

Jobs - 어떤 작업을 실행하고 싶은지

Job

Job은 작업 단위를 의미하며, 각자 실행할 환경을 가지고 있습니다. Job은 jobs.<job_id>이라는 고유 식별자를 부여하여 실행할 수 있습니다. (이 때 고유 식별자는 문자열입니다.)

jobs:
  my_first_job:
    name: My first job
  my_second_job:
    name: My second job

Job : 작업이 실행되기 전, 성공적으로 완료되어야 하는 작업 설정

작업이 실행되기 전에 성공적으로 완료되어야 하는 작업을 식별하려면 jobs.<job_id>.needs를 사용할 수 있습니다.

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

Runner - 실행 환경을 변경하고 싶다면

각 작업은 jobs.<job_id>.runs-on 으로 지정된 러너 환경에서 실행됩니다. Git Actions에서 기본으로 제공하는 환경은 window, ubuntu, macos이며 제공하는 버전을 선택해서 구성할 수 있습니다.

jobs:
  runs-on: ubuntu-latest

Job의 Runner를 다양한 환경으로 구성하고 싶다면 다음과 같이 구성할 수 있습니다.

runs-on: [windows-latest, linux-latest, macos-latest]

추가로 matrix를 이용하면 실행하려는 구성도 다양하게 구성할 수 있는데, 아래 matrix에서 다뤄보겠습니다.

Job의 Runner를 원하는 환경에 구성하고 싶다면 runs-on에 self-hosted 러너 라벨을 사용해 구성할 수 있습니다.

runs-on: self-hosted

self-hosted라벨을 설정하는 방법은 repository의 settings 에 들어가서 runners 목록에서 관리할 수 있습니다.

Matrix - 여러 환경에서 실행하고 싶다면

Matrix를 활용한 운영 환경 설정

아래와 같이 구성한다면 세 개의 os 환경과 두 개의 자바 버전을 이용해 테스트를 진행할 수 있습니다.

jobs:
  build:
    strategy:
      matrix:
        os: [ubuntu-latest, macos-latest, windows-latest]
        version: [11, 17]
      fail-fast: false

    runs-on: ${{ matrix.os }}
    
    steps:
      - uses: actions/checkout@v3
      - name: 🛠 Set up JDK 17
        uses: actions/setup-java@v3
        with:
          java-version: ${{ matrix.version }}
          distribution: 'corretto'

이렇게 구성한다면 총 6 번의 작업이 실행되게 됩니다.

Matrix를 활용한 구성 환경 설정

Git Actions docs에 따르면 구성 환경 설정도 변경하면서 작업을 실행할 수 있으니 활용할 수 있는 방안이 많습니다.

strategy:
  matrix:
    fruit: [apple, pear]
    animal: [cat, dog]
    include:
      - color: green
      - color: pink
        animal: cat

위와 같은 matrix는 아래와 같은 조합을 완성할 수 있습니다.

• {fruit: apple, animal: cat, color: pink, shape: circle}
• {fruit: apple, animal: dog, color: green, shape: circle}
• {fruit: pear, animal: cat, color: pink}
• {fruit: pear, animal: dog, color: green}
• {fruit: banana}
• {fruit: banana, animal: cat}

많은 방법을 제공하지만, matrix를 많이 활용할 수록 가독성이 떨어진다는 단점도 보입니다.

Condition : 조건에 따라 실행 여부를 결정하고 싶다면

jobs.<job_id>.if 조건문을 사용하여 조건이 충족되지 않으면 작업이 실행되지 않도록 할 수 있습니다. Git Actions에서 사용할 수 있는 방법은 env에서 설정한 환경과 같은지, github 이벤트와 같은지를 비교할 수 있습니다.

step 실행 여부를 env로 결정하는 방법

특정 환경에서만 실행할 수 있도록 설정할 수 있습니다.

env:
  DAY_OF_WEEK: Monday

jobs:
  greeting_job:
    steps:
      - name: "Say Hello Mona it's Monday"
        if: ${{ env.DAY_OF_WEEK == 'Monday' }}
        ...

workflow 파일에서 설정한 env 말고도 secrets에 설정한 정보도 활용할 수 있으니 민감한 정보들은 secret에서 관리하면 됩니다.

job 실행 여부를 github event 로 결정하는 방법

아래와 같이 머지되는 상황에서만 작업을 실행할 수 있도록 설정할 수 있습니다.

build_and_containerization:
    if: github.event.pull_request.merged == true
    ...

무조건 실행하고 싶은 경우

Git Actions는 상위 Job이 실패하면 작업이 중단되는 특성이 있는데, 만약 상위 Job 성공 여부와 관계없이 실행 시키고 싶다면 always() 를 사용할 수 있습니다.

jobs:
  job1:
  job2:
    needs: job1
  job3:
    if: ${{ always() }}
    needs: [job1, job2]

마지막으로

Git Actions를 학습하면서 장단점을 파악해 활용률을 높여보려 합니다.

Git Actions 활용률 높이기

Git Actions 장점

• 작업 단위로 쉽게 관리할 수 있다.
• 다양한 기능을 제공한다.
• 간단한 CI를 구성할 때는 쉽게 사용할 수 있다.

Git Actions 단점

• 원하는 데로 사용할 때 신경써야할 부분이 있다.
• Git Actions가 문제가 발생하면 이후의 작업을 수행할 수 없다.

Git Actions 보완할 방법

• 실패한 Workflow를 재시도하는 스케줄러를 추가한다.

정리하면서

Git Actions가 제공하는 기능이 많아서 학습하는 시간이 오래 걸렸습니다. 다른 사용자들은 이 글을 읽고 쉽게 이해했으면 하는 마음으로 정리했습니다. 다음에는 Git Actions를 활용해 어떻게 테스트 파이프 라인을 구성했는지를 정리해보겠습니다.