[Project] Github Actions를 통한 CI 환경 구축하기

bagt13·2023년 3월 15일

CI/CD github actions 테스트 자동화

Project

목록 보기

6/17

이전 포스트 (Jenkins CI/CD 적용기)

Jenkins를 통한 CI/CD 파이프라인 구축 (2)

🖥️ 적용 계기

협업 시 코드의 안정성은 가장 중요한 요소 중 하나이다. 여러 사람이 코드를 수정하기 때문에 다른 사람이 수정한 코드로 인해 테스트에 실패할 수 있다. 또한 내가 작성한 코드가 테스트를 통과하는지 다른 사람은 알 수 없다. 신뢰도, 안정성이 보장되지 않은 상태로 merge가 일어나는 일은 피해야 한다.

♻️ 테스트 자동화를 통한 코드 안정성 보장

흔히 CI(Continuous Integration)라고 부르는, 지속적 통합을 통해 이러한 코드의 안정성을 보장할 수 있다.

사실 나는 이미 Jenkins Pipeline을 통해 build를 실행하고 있었지만, Github Actions를 통해 build에 실패할 경우 merge를 금지하는 등 다양한 기능을 사용할 수 있었고, Github Actions 복습 겸 구축하게 되었다.

나는 다음의 상황에서 CI trigger가 발생하도록 했다.

main/dev branch로의 push 또는 merge가 일어날 경우

Pull Request가 발생할 경우

gradle.yml 작성

name: Java CI with Gradle

# CI trigger 설정
on:
  push:
    branches:
      - main
      - dev
  pull_request:
    branches:
      - main
      - dev

# 아래의 jobs가 실행될 경로를 명시해준다.
defaults:
  run:
    working-directory: server/fly-away

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v3
        with:
          token: ${{ secrets.SECURITY_TOKEN }}
          submodules: recursive
      
      - name: Set up JDK 11
        uses: actions/setup-java@v3
        with:
          java-version: '11'
          distribution: 'temurin'
          cache: gradle
          
      - name: init with Gradle
        uses: gradle/gradle-build-action@v2
        
      - run: gradle init
      
      - name: Build
        run: ./gradlew build

기본적으로 jobs - steps의 구조로 되어있으며, steps 하위에 실행할 동작들을 명시해주면 된다.

name : 각 step의 이름을 지정한다.
uses : 외부 라이브러리를 활용할 때 해당 라이브러리를 선언해준다.
with : 라이브러리에 대한 추가적인 옵션 또는 설정을 선언해준다.

submodule 설정 부분

steps:
    - name: Checkout
	  uses: actions/checkout@v3
	  with:
	  	token: ${{ secrets.SECURITY_TOKEN }}
	 	submodules: recursive

checkout 시 submodule에 대한 권한을 부여해야 한다.
Repository의 Settings -> Secrets -> Actions에서 시크릿 값을 설정해주고, submodule에 접근하기 위한 token으로 사용한다.
submodules: recursive 옵션을 사용하면 submodule update까지 자동으로 실행해준다.

✅ 빌드/테스트 성공

❌ 테스트 실패 시 Merge가 불가능하도록 한다.

현재는 Pull Request 시 빌드/테스트를 진행하지만, 개발자가 임의로 PR을 Merge 할 수 있는 상황이다. 물론 테스트 성공 여부를 확인하고 merge 할 수도 있지만, 개발자의 실수로 인해서라도 Merge가 발생할 수 있으므로 테스트 실패 시 Merge가 불가능하도록 해보자.