Github Actions 알아보기

처음에는 CI/CD 도구로 비교적 간편한 CI/CD 도구인 Github Actions를 사용하려고 했지만, 우테코 Organization 권한 문제로 CD를 진행할 수 없었다. CI는 Github Actions로 진행하고, CD는 젠킨스로 진행하기로 했다. 간단하게 Github Actions에 대해 알아보려고 한다.

 

Github Actiosn에서는 특정 레포지토리에 대한 PullRequest가 열리거나 Issue가 열리는 등의 이벤트가 트리거 되도록 workflow를 구성할 수 있다. workflow에는 1개 이상의 순차적으로 실행되거나 병렬적으로 실행되는 jobs를 포함할 수 있다. 각각의 job은 자체 virtual machine runner나 컨테이너 내부에서 실행된다.

 

구성요소

WorkFlow

workflow는 하나 이상의 jobs를 실행하는 구성 가능한 자동화 프로세스이다. yml 파일에 의해 정의되고 트리거에 의해 실행된다.

 

Event

Event는 workflow 실행을 트리거하는 리포지토리의 특정 활동이다.

ex) 누군가가 pull 요청을 생성하거나, 이슈를 열거나, 커밋을 리포지토리에 푸시할 때

 

Job

Job은 동일한 Runner에서 실행되는 workflow의 일련의 단계이다. 각 단계는 실행될 셸 스크립트이거나 실행할 action이다. 단계는 순서대로 실행되며 서로 종속된다. 각 단계는 동일한 러너에서 실행되기 때문에 한 단계에서 다른 단계로 데이터를 공유할 수 있다.

다른 작업과의 종속성을 구성할 수 있다. 기본적으로 작업에는 종속성이 없으며 서로 병렬로 실행된다. 작업이 다른 작업에 종속되면 종속 작업이 완료될 때까지 기다렸다가 실행할 수 있다.

 

Step

Step은 커맨드를 실행할 수 있는 각각의 Task를 의미하는데, Shell 커맨드가 될 수도 있고, 하나의 Action이 될 수도 있다.

하나의 Job 내에서 각각의 Step은 다양한 Task로 인해 생성된 데이터를 공유할 수 있다.

 

Action

Action은 복잡하지만 자주 반복 되는 작업을 수행하는 GitHub Actions 플랫폼용 사용자 지정 응용 프로그램이다. Action을 사용하여 workflow 파일에 작성하는 반복적인 코드의 양을 줄일 수 있다. GitHub에서 git 리포지토리를 가져오거나, 빌드 환경에 대한 올바른 도구 체인을 설정하거나, 클라우드 공급자에 대한 인증을 설정할 수 있다.

 

Runner

Runner는 workflow가 트리거 되었을 때 실행되는 서버이다. 한번에 하나의 job을 수행할 수 있다. 각 workflow는 새로 공급된 서버에 의해 workflow가 실행된다.

 

Workflow 작성

위의 개념들을 기반으로 Workflow를 작성해보았다.

name: gongseek backend CI

# Workflow를 실행시키기 위한 이벤트 목록 
# 모든 브랜치에 대한 PR이 열릴 때 마다
# backend 하위 패키지에 변경이 일어날 때만 작동
on:
  pull_request:
    branches:
      - '*'
    paths:
      - backend/**

jobs:
  # job의 이름
  build:
  	
    # 실행될 환경
    runs-on: ubuntu-22.04
	
    # 작업을 수행하기 위한 기본 경로
    defaults:
      run:
        working-directory: ./backend

    steps:
      # 소스코드로 체크아웃
      - uses: actions/checkout@v2
	  # 서버에 자바 버전 설치
      - name: Set up JDK 11
        uses: actions/setup-java@v1
        with:
          java-version: 11

	  # Gradle 권한 변경
      - name: Grant execute permission for gradlew
        run: chmod +x ./gradlew

	  # 빌드 진행
      - name: Test with Gradle
        run: ./gradlew build

	  # 테스트 결과를 커멘트로 등록
      - name: Register test results as comments in PR
        uses: EnricoMi/publish-unit-test-result-action@v1
        if: always()
        with:
          files: '**/build/test-results/test/TEST-*.xml'

	  # 테스트 실패 시, 코드라인에 체크 커멘트 등록
      - name: If the test fails, register a Check comment in the failed code line
        uses: mikepenz/action-junit-report@v3
        if: failure()
        with:
          report_paths: '**/build/test-results/test/TEST-*.xml'
          token: ${{ github.token }}

	  # 빌드 실패 시, 슬랙으로 알람
      - name: If build fails, notify Slack
        uses: 8398a7/action-slack@v3
        with:
          status: ${{ job.status }}
          author_name: 백엔드 빌드 실패 알림
          fields: repo, message, commit, author, action, eventName, ref, workflow, job, took
        env:
          SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
        if: failure()

 

마무리

Gihub Actions work flow를 작성한 후, 정말 간편하게 구성할 수 있다는 것을 깨달았다. Jenkins와 같은 다른 CI/CD 툴은 별도의 설치가 필요하지만 별도의 환경을 구성하지 않아도 된다는 점에서 좋았다. 그리고 기존의 action들을 활용할 수 있다는 점과 문법이 어렵지 않다는 점이 많은 사람들이 CI/CD 툴로 Github Actions를 쓰는 이유가 아닐까 싶다.

 

참고

https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions