깃허브 액션(GitHub Actions)을 이용해서 지속적 통합(CI)할 때의 흐름 알아보기

🚀 이번 포스팅 목표

• GitHub Actions를 사용하는 포스팅보다 어떤 식으로 동작되는지 흐름을 보도록 한다.
• GitHub Actions의 Runner에 대해서 이해한다.
• GitHub Actions의 Event에 대해서 이해한다.
• GitHub Actions의 Jobs에 대해서 이해한다.
• GitHub Actions의 Steps에 대해서 이해한다.
• GitHub Actions의 Action에 대해서 이해한다.
• GitHub Actions를 이용해서 push 했을 때 스프링 프로젝트를 빌드하도록 설정한다.

 

📌 상황 설명

현재 브랜치가 feature, develop가 있다고 하자.
팀 프로젝트를 진행하면서 feature 브랜치로부터 develop 브랜치에 push를 자주하고 있다.
이후에 develop 브랜치를 가지고 배포하려고 할 때 두려움에 떠는 상황을 최대한 피하고 싶었다.
그래서 develop 브랜치에 push 될 때 마다 build를 자동화 시켜 코드 통합이 잘 되었는지 확인하는 작업을 자동화하려 한다.
(줄여 말하면 CI...)
 
 

🤔 먼저 어떤 작업이 있어야 할지 생각해보자.

• [GitHub Actions] develop 브랜치에 Push 할 때를 감지한다.
• [GitHub Actions] develop 브랜치의 코드를 빌드한다.
  • 현재 스프링 코드를 빌드하기 위해서는 JDK 17이 존재해야 한다.
  • 현재 스프링 코드를 빌드하기 위해서는 Gradle이 필요하다.

 
 

🟩 깃허브 호스트 러너(GitHub-hosted runners)

GitHub Actions를 이용해서 스프링 코드를 어떻게 테스트해야할까?
 
깃허브에서는 워크플로(workflow)를 실행할 호스팅된 가상 머신(VM, 컨테이너)을 제공하고 있다.
깃허브 호스트 러너(GitHub-hosted runner)를 통해서 레포지터리를 로컬에 복제하고, 테스트하는 명령을 실행할 수도 있다.
(지금은 워크플로를 하나의 작업 단위라고 생각하고 넘어가자.)
 
러너에는 러너 애플리케이션 및 기타 도구가 미리 설치된 깃허브에서 제공하는 가상 머신으로 Ubuntu Linux, Windows, macOS 운영체제를 이용할 수 있고 이처럼 작업을 실행하는데 사용할 수 있는 공간을 제공한다고 이해하자.
 
깃허브 호스트 러너에 대한 존재를 알고 있다면 이제 원하는 작업을 위해 다음과 같은 구성이 존재해야한다는 것을 생각할 수 있다.

• Ubuntu Linux 환경을 만든다.
• 작업한 Repository를 받아온다.
• JDK 17을 설치한다.
• Gradle를 통해서 빌드한다

 
 
 

🟩 워크플로(workflow)

방금까지 깃허브 호스트 러너에 대해서 얘기하면서 어디서 테스트가 진행되는지 알아봤다.
이번에는 작업이 자동으로 실행될 수 있도록 "워크플로"라는 프로세스에 대해서 알아보자.
 
워크플로는 하나 이상의 작업을 실행하는 자동화 프로세스이다.
GitHub Actions에서는 레포지터리에 다른 이벤트(event)가 발생할 때 이러한 워크플로를 실행할 수 있다.
워크플로는 레포지터리에 체크인한 YAML 파일로 만들 수 있으며
레포지터리의 `.github/workflows`  디렉터리에 각각 다른 작업을 수행하는 여러 워크플로를 정의할 수 있다.
 
워크플로는 이벤트 발생으로 인해 실행되고 여러 개의 러너(runner)가 생성될 수 있다.
각 러너에는 작업(Job)들이 존재하고 작업을 세분화해서 본다면 스텝(Step)들이 존재한다.

잠시 깃허브 호스트 러너에 대해서 짚고 넘어가자.
러너는 각 하나의 컨테이너를 갖고 있다. 러너가 두 개 존재한다는 말은 두 개의 컨테이너를 사용하고 있다고 생각하면 된다.
컨테이너가 분리되어 있다는 말은 서로 다른 정보를 가지고 있음에 주의하자.

 
 
 
 
이번 포스팅 목표로 develop 브랜치에 push 이벤트가 발생할 때 build를 자동화하여 지속적 통합(CI)을 구성하는 것이다.
먼저 목표에 맞게 작성한 워크플로에 주석을 보면 위 그림과 같은 형태와 비교할 수 있다는 것을 알 수 있다.
물론 아래 워크플로는 러너를 하나만 사용하고 있다.

# .github/workflows/github-actions-ci.yml

name: test-actions CI

# 이벤트
on:
  push:
    branches:
      - develop

# 작업 목록
jobs:
  build:
    # 러너 환경
    runs-on: ubuntu-latest

    # 스텝 목록
    steps:
      # Step 1 : Run Action
      - name: Current Repository Checkout
        uses: actions/checkout@v3
        
        
      # Step 2 : Run Action
      - name: Java 17 설치
        uses: actions/setup-java@v3
        with:
          java-version: 17
          distribution: temurin
          
          
      # Step 3 : Run Action
      - name: Gradle Wrapper Validation
        uses: gradle/wrapper-validation-action@v1
  
  
      # Step 4 : Run Action
      - name: Gradle Build Action
        uses: gradle/gradle-build-action@v2.6.0
        with:
          arguments: build

위에 작성한 워크플로는 아래와 같은 흐름을 갖게된다.

 
 
 
 
 

🟩 이벤트(Events)

Event는 워크플로 실행을 트리거(trigger)하는 레포지터리의 특정한 활동을 의미한다.
누군가 push하거나, issue를 열거나, pull request할 때 실행되도록 워크플로를 트리거할 수 있다.
 
 
다음과 같은 .github/workflows/example.yml이 있다고 했을 때
on 속성을 통해 워크플로가 언제 실행되는지 정의할 수 있다.
push 속성을 넣어 push 이벤트가 발생할 때 워크플로를 실행하도록 한다.

on:
  push:

 
 

🟩 러너 (Runner)

Runner는 트리거될 때 워크플로가 실행될 서버이다.
서버는 GitHub Actions runner application가 설치되어 있어 GitHub Actions workflow로부터 Job을 실행시켜주는 애플리케이션이다. 각 러너는 한 번에 하나의 작업을 실행할 수 있고 GitHub는 Ubuntu Linux, Windows, macOS 러너를 제공하고 있다.
각 워크플로는 새로운 가상 머신(러너)에서 실행된다.
 
 
 

🟩 작업 (Jobs)

GitHub Actions에서 작업이란 가상 머신(컨테이너)에서 수행되는 단위를 의미한다.
하나의 워크플로에는 여러 개의 작업이 있을 수 있고 하나 이상의 작업이 존재해야 한다.
기본적으로 모든 작업은 동시에 실행되지만 필요하다면 작업 간에 의존 관계를 설정해서 실행 순서를 제어할 수 있다.
각 단계는 동일한 러너에서 실행되므로 한 단계에서 다음 단계로 데이터를 공유할 수 있다.
 
runs-on 속성을 넣어 unbuntu 최신 버전을 실행 환경으로 지정할 수 있다.
여기서 `build`는 명령어가 아닌 작업 단위명을 지정해준 것이라고 이해하자.
즉, 작업 목록 중에 build라는 이름을 갖는 작업을 하나 만들었다.

jobs:
  build:
    runs-on: ubuntu-latest

 
 

🟩 스텝 (Steps)

여러 단계의 명령을 순차적을 실행하기 위한 작업을 하나 이상의 단계로 모델링한다.
작업 단계에서는 커맨드, 스크립트 또는 액션일 수도 있다.
run 속성을 통해 커멘드나 스크립트를 실행시킬 수 있다.
uses 속성을 통해 액션을 사용할 수도 있다.

# 작업 목록
jobs:
  build:
    # 러너 환경
    runs-on: ubuntu-latest

    # === 스텝 목록 (Steps) ===
    steps:
      # Step 1 : Run Action
      - name: Current Repository Checkout
        uses: actions/checkout@v3
        
        
      # Step 2 : Run Action
      - name: Java 17 설치
        uses: actions/setup-java@v3
        with:
          java-version: 17
          distribution: temurin
          
          
      # Step 3 : Run Action
      - name: Gradle Wrapper Validation
        uses: gradle/wrapper-validation-action@v1
  
  
      # Step 4 : Run Action
      - name: Gradle Build Action
        uses: gradle/gradle-build-action@v2.6.0
        with:
          arguments: build

 
 
 
 

🟩 액션 (Actions)

Action은 복잡하지만 자주 반복되는 작업을 수행하는 GitHub Actions 플랫폼용 사용자 지정 애플리케이션이다.
Action을 사용해서 워크플로 파일에 작성하는 중복 코드 양을 줄이고 레포지터리를 가져오거나 빌드 환경을 설정하는 등의 행동을 할 수 있다.
 
다음과 같이 uses 속성을 이용해서 Action을 사용한다.
actions/checkout@v3는 레포지터리를 가져오면서 사용할 수 있는 여러 정보를 가져오게 된다.

# === Step 1 : Run Action (Action) ===
- name: Current Repository Checkout
  uses: actions/checkout@v3

 
 
 
 

🟩 결과적으로

다음과 같이 develop 브랜치에 .github/workflows/github-actions-ci.yml 설정을 두었다.

이제 다음과 같이 develop 브랜치에 push 할 때 트리거가 워크플로를 실행하게 된다.
아래는 작성한 워크플로에 대한 작업 내용이다.