Github Workflow

최근에 개인 프로젝트를 하면서, workflow를 작성할 일이 있어 정리한 내용들을 가지고 왔다.

공식 문서를 보면서 작업을 했지만 문서 내에 있는 내용들을 전부 블로그에 옮기는 것보다 우선적으로 많이 사용하는,

실제로 사용했던 필드들을 기준으로 가지고 왔다.

---

한 번 세팅해 두면, 생산성뿐 아니라 여러모로 편리한 만큼 많은 Git을 사용하는 거의 모든 회사들이 Github Action을 사용하고 있지 않나 싶다. Github Action을 사용할 때 작성하게 되는 workflow 파일들에 대해서, 오늘은 좀 다뤄보고자 한다.

그중에서도, workflow에서 자주 사용하거나 필수적으로 작성해야 하는 필드들을 먼저 가지고 왔다.

 

Workflow?

서론에서도 살짝 다뤘듯, Github Action에서 일어나는 작업들을 정의한 파일이라고 생각하면 된다.

기본적으로 YAML 파일이므로 YAML Syntax를 따라가고, 최소 한 개 이상의 job을 포함하고 있어야 실행이 가능하다.

 

name

공식 문서에서 가장 먼저 마주하는 필드로 workflow의 이름, github action에서 노출될 때 보이는 이름이 된다.

name: Github_Workflow

 

여기에 노출되는 이름이 된다. 즉, 사진 상의 Github action에는 Deploy라는 이름의 workflow가 등록되어 있다는 말이 된다.

on

workflow가 동작하는 시점을 의미한다, 문서에서는 트리거라고 정의되어 있다.
push, pull_request, issue, label 등 깃허브 내에서 작동하는 명령어들을 사용 수 있으며 하위 레벨로 더 디테일한 설정이 가능하다.

push를 이용한 기본 테스팅, pull_request로 메인 브랜치에 합치기 전 테스트를 진행하거나, workflow_run을 이용해 pr 테스팅 완료 이후 배포 workflow를 돌린다거나, workflow_dispatch를 이용해 수동으로 해당 workflow를 이용할 수 있도록 하는 정도까지 평소에 많이 사용하고 있으며, workflow_call을 이용해서 secrets를 사용하도록 설정하는 것 정도가 제일 보편적인 사용사례가 아닐까 한다.

on:
   pull_request: 
    	branches: [ "master" ] 
# master branch로의 pull_request가 일어날 때 작동함을 알 수 있다. 

on: [push, pull_request] 
# 위 처럼 여러 명령어를 트리거로 넣을 수 있다.

참고로 네거티브 패턴과 포지티브 패턴을 지원해서, 아래와 같이도 사용이 가능하다

on: 
	push: 
    	branches: 
        	- 'feat/**' 
            - '!feat/**-dev' 
            
# 브랜치 이름 중 feat/ 를 포함하는 모든 브랜치에 대해 
# push 이벤트가 발생하면 workflow를 실행하지만, 
# -dev를 포함하고 있다면 실행하지 않는다.

 

뿐만 아니라, cron 형태의 schedule을 지원하므로 배포까지의 개발이 마무리되어 있고 정해진 시간에 맞추어 배포를 하는 게 일상적이라면, schedule을 이용해서 배포하는 방식도 충분히 가능하다.

 

이 외에도, issue나 fork, pull_request_review, create, delete 등 다양한 명령어들을 지원하고 있으며, 각각에 대한 자세한 설명과 종류가 알고 싶다면, 공식문서를 확인해 보시길 바란다.

 

env

환경 변수를 의미한다, 모든 workflow에 적용하려면 상단에 위치시켜야 하고 특정한 workflow에만 적용시킨다면, job 아래의 속성으로 설정할 수도 있다. 전체 환경 변수가 있고, job에 환경변수가 또 있다면 해당 job에 설정한 환경변수를 따라간다

 

concurrency

작업에 대한 workflow 동시성을 설정하는 옵션이다.

동시에 여러 작업이 실행된다면 이 옵션에 따라 기다린 이후 실행되거나 먼저 진행하고 있는 작업들을 종료하고 현재 workflow를 실행하는 등의 설정이 가능하다.

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true
# 동일한 workflow가 기존에 실행 중이라면, 종료하는 코드

 

jobs

env, concurrency는 없어도 사용하는데 크게 지장이 없지만, on과 jobs가 없으면 workflow가 동작하지 않는 셈이니, 매우 중요한 요소라고 할 수 있다. required라 jobs가 없는 workflow는 사실상 없다.

 

기본적으로 각각의 job은 병렬적으로 실행된다.

jobs:
	build:
	deploy:
# build라는 id의 job과 deploy라는 id의 job 설정
# 각각은 workflow 실행시 병렬적으로 작업이 들어감

 

 

대표적인 Jobs 내의 필드는 다음과 같다.

• name, job에도 이름을 설정할 수 있다. 하위에 name이라는 변수와 같이 설정할 이름을 달아주면 job의 이름이 되고 실행 시에 이름을 확인할 수 있다.
• runs-on (required), 실행될 시스템을 의미한다. github에서 제공하는 runners를 이용해도 괜찮고, 각자가 가지고 있거나 빌드용 pc가 있다면 이것들을 self-hosted runner로 등록해서 사용해도 된다. github runners의 가격이 생각보다 많이 나가므로, 개인적으로는 빌드용 pc나 개인 컴퓨터를 이용한 self hosted runner를 구성하는 것을 추천한다.
• steps, job 내에서 실행될 각각의 일들을 의미한다. 코드를 체크아웃하거나, 빌드를 하거나 하는 것들이 steps 아래에 각 step으로 정의된다.
  
  • uses, steps 아래에서 사용될 기 정의된 코드 조각들
  • run, steps 아래에서 작동될 커맨드, runs-on에 설정된 runner 환경에서 실행됨을 인지하자

 

 

기본적인 필드는 설명했으니, flutter로 애플리케이션을 만들어 Deploy라는 이름의 workflow를 아래와 같이 만든다고 가정해 보자

1. github hosted runner는 가격이 비싸 내 컴퓨터를 이용해 workflow를 구성하기로 했고,
2. master 브랜치에 PR이 만들어지면
3. 코드들이 플랫폼 별로 빌드가 정상적으로 되는지 확인하고 싶다.

# 먼저, 이름을 입력하자
name: Deploy

# 실행은 master branch에 PR이 만들어졌을때
on:
  pull_request:
    branches: 
      - master

# 내 컴퓨터를 self-hosted runner로 이용
jobs:
  build:
    runs-on: self-hosted
    
    # 플랫폼 별 빌드 확인
    steps:
      - uses: actions/checkout@master
      - name: Pub Get, Initialize Default settings
        run: flutter pub get
      - name: Android Build test
        run: flutter build appbundle
      - name: iOS Build test
        run: flutter build ios

여기까지 했다면, 빌드 테스트가 가능한 CI 정도가 구성되었다고 할 수 있겠다.

조금 더 응용한다면, 앞선 단계에서 각각 프로젝트에서 사용하는 테스트를 진행한다거나, 뒷 단계에 fastlane과 같은 배포 지원 툴을 이용해 실제 심사 직전 단계까지의 과정을 한 workflow로 담는다거나 하는 것도 어렵지 않게 가능하다.

 

기본적으로 self-hosted runner를 사용하던 github runner를 사용하던, 현재 repository 내 특정 브랜치의 소스 코드와 runner의 환경을 이용해 빌드 및 커맨드를 사용해 구성하는 것이므로 CLI가 익숙하다면 충분히 다른 기능도 구현할 수 있다.

 

최근에 GPT를 이용해 PR 생성된 코드의 리뷰를 달아주는 workflow를 재미있게 봤었다. 사용도 했었는데, 가끔은 반영해 볼 만한 코드리뷰를 제공해 줘서 좋았으나 프로젝트 단위의 요구사항을 모르기도 하고 코드 전체 맥락을 본다기보다는 변경 점 위주의 리뷰를 달아줘서 의미 없는 리뷰가 남는 경우들이 대다수였다. 계속 개선해 나가고 있다고 하니, 점점 더 좋아지지 않을까? 

궁금하다면, https://github.com/anc95/ChatGPT-CodeReview

 

self-hosted runner 설정과 관련된 글을 먼저 작성하려고 했으나, 내용을 정리하던 중 순서가 꼬여 workflow 먼저 작성하게 되었다. 

다음번에는 self-hosted runner와 fastlane을 적용하면서의 시행착오를 담아 볼 예정이다.