[iOS] Github Action 이용 - Build

이번에 회사에서 사용하는 Github이 드디어 업데이트 되면서, Github Action을 사용할 수 있게 되었습니다 :)

당연히 새로운게 나왔으니 사용하고 싶었고, 단점보다는 장점이 많은 것 같아 바로 도입하게 되었습니다.

 

기존에는 Jenkins + fastlane로 CI/CD가 설정되어 있었고 여기서 CI 과정만 Github Action로 대체해보았습니다~

그렇다면 옮기면서 공부한 것과 Github Action이 무엇인지 알아볼게요.

 

Github Action

Github Action이란게 특별한게 있는 건 아닙니다 ㅎㅎ.. 그냥 기존에 CI/CD 역할을 할 수 있는 많은 툴 들이 있잖아요. 그 중에 Github에서 만든 하나의 툴입니다.

Build, test, and deploy your code. Make code reviews, branch management, and issue triaging work the way you want (설명)

 

우선 제가 세웠던 목표는 CI 과정을 Jenkins -> Github Action으로 Migration 하는 것이였습니다.

여기서 CI 빌드를 돌리는 규칙은 다음과 같았습니다 (이건 팀마다 다르니 참고만하시면 될 것 같습니다.)

• release, feature, working 브랜치로 PR
• master, release 브랜치로 Push

 

위의 규칙에 맞게 이제 Github Action을 설정해보겠습니다~

 

먼저 Github Repository의 Action 탭으로 이동해서, Swift에 보이는 Set up this workflow를 선택해줍니다.

(아마 본인 Repository가 Swift로 되어 있으면 자동으로 추천해주는 것으로 알고 있습니다)

선택하게 되면, 기본으로 빌드를 할 수 있는 .yml 파일이 하나 추가됩니다. 

이제 저는 이 .yml을 저의 프로젝트 세팅에 맞게 설정해볼건데요. 

 

개인적으로 커스텀이 필요한 분들은 밑의 링크에서 확인해서 환경에 맞게 설정하면 될 것 같습니다.

Learn GitHub Actions - GitHub Docs

 

우선 Triggering 되기 위한 Event를 위에서 2가지로 정의했었죠?

그 부분을 여기서 .yml 파일에 설정해 줄 것입니다.

(밑에서 조건을 거는 것 외에도 특정 시간마다 반복 등의 Event 발생 조건도 커스텀이 가능하니 필요한 분들은 위에 나와있는 링크를 확인해서 설정하시면 될 것 같습니다.)

 

master, release 브랜치로 push 왔을 때, 실행하기

on:
  push:
    branches:
      - master
      - release/**

 

release, feature, working 브랜치로 PR 왔을 때, 실행하기

on:
  pull_request:
    - release/**
    - feature/**
    - working/**

 

 

이제 다음으로는 CI 과정의 Build를 위해서 하나의 Job을 커스텀 해줄 것입니다..!!

일단 Build를 하기 위한 과정은 다음과 같습니다.

1. Repository로 Checkout
2. Library의 특정 버전 추출을 위한 Shell Script (이 과정은 설정마다 다를 것 같네요 ㅎ)
3. Cocoapod Install
4. Fastlane 이용한 Build

 

이 과정들을 .yml 파일에 작성해줄 것 입니다.

jobs:
   build:
     # Job이 실행될 환경 - 빌드 머신이 있기 때문에, 호스팅을 지정 (나중에 별도 설정 필요)
     # 또한 vpn 환경으로 실행되어야 하기 때문에, 별도의 host를 지정
     runs-on: self-hosted
     
     steps:
     # Repository로 Checkout - 기존에 만들어져있는 Action 활용
     - uses: actions/checkout@v2
     
     # 회사에서는 특정 Library의 버전을 추출할 필요가 있기에 추출 - RxSwift는 예시
     - name: Library Version 추출
       run: |
         RESULT=$(grep pod..RxSwift., Podfile)
         sed -i '' "s/pod .RxSwift., .[0-9]*.[0-9]*.*./$RESULT\"/" ./fastlane/.env  
         sed -i '' "s/ *pod/pod/" ./fastlane/.env
         
     # 빌드 전, Cocoapod install
     - name: Cocoapods Install
       run: pod install --repo-update
       
     # 기존에 정의되어 있는 lane 실행
     - name: Fastlane Build
       run: fastlane github_action_build

 

여기서 저는 하나의 Job을 실행하기 위해 self-hosted 환경을 선택했는데요. 

 

회사에서는 접근을 위해 VPN 환경으로 접속해야하기 때문에, 별도 접근이 가능한 host를 지정하였습니다. 

만약 설정이 필요하신 분들은 밑의 링크를 참고하면 좋을 것 같습니다.

Adding self-hosted runners - GitHub Docs

위의 .yml 구문에 대해서는 주석을 이용해서 조금씩 설명이 되었는데요. 뭔가 구조가 혹시 보이시나요?

indent가 중요한데 indent 별로 단계를 가지게 됩니다. 

 

Github Action에서 용어가 있는데요. 한번 같이 보겠습니다.

크게 Github Action에서 설명하는 구조는 Workflow -> Job -> Step -> Action으로 구성됩니다.

위의 .yml 파일에서도 해당 구조가 나타나는데요.

• Workflow = .yml
• Job = build 구문
• Step = actions/checkout@v2, Library Version 추출, Cocoapod Install, Fastlane Build
• Action = Step 안의 각각의 구문들(?)

 

이렇게 각 indent별로 구분되어 있는 것 같습니다. (여기서 Step, Action의 구분이 조금 모호하긴 한데.. 아마 저게 맞지않을까 생각합니다.)

 

자 이렇게하면 이제 사용할 준비는 완료되었습니다~

아까 위에서 설정한 Triggering에 해당하는 PR을 올리고 한번 PR에서 빌드가 잘되는지 확인해볼게요.

 

실패하는 경우

 

성공하는 경우

이렇게 각각의 경우를 확인할 수 있습니다. 

 

만약, 실패한 경우에 다시 PR에 Push하고 재빌드를 원하면 저기 보이는 Details 버튼을 누르고 들어가서 Re-run all jobs를 클릭해주면 다시 workflow를 실행할 수 있습니다.

 

이렇게 오늘은 Github Action을 이용해서 간단하게 Build를 실행하는 것까지 해보았는데요.

사용하면서 느낀 장점들은 몇가지 있었습니다.

 

우선, Github에서 만들어준 것이기 때문에 Git과의 연동성이 좋았습니다. 기존의 Jenkins의 경우에는 많은 플러그인 설치, Auth 설정의 과정이 필요한데 Action의 경우에는 이런 것들이 간단했습니다. 

 

또한 Git과의 연동성이 좋기 때문에, PR 상에서 빌드가 성공하는지 확인할 수 있다는 점도 장점일 것 같습니다. 기존의 Jenkins의 경우에는 PR이 올라가고 별도로 빌드가 돌아가기 때문에 따로 노는 느낌이었는데 Action은 그렇지 않았습니다 ㅎㅎ

 

다음으로 느껴졌던 장점은 기존의 작성했던 Script를 활용할 수 있어서 Migration하는 과정이 크게 어렵지 않았습니다 :)

 

각자의 배포 주기에 맞게 Github Action을 설정해서 사용하면 많이 유용할 것 같네요.

혹시 포스팅에서 잘못된 내용이 있으면 댓글로 남겨주세요~

감사합니다 🙃