[Github Actions] Github Actions를 사용해보자 - 1. 기본 개념 정리

CI/CD Tool 중 Github에서 제공하는 Github Actions라는 Tool을 사용해 보았다.

 

Github Actions을 적용하는 예제를 작성한 많은 게시글을 확인할 수 있었는데, 가이드를 보아도 필자는 정상적으로 설정하는 것 까지의 시간이 상당히 오랜시간이 걸렸다.

 

글을 작성하다보니, 생각보다 길이가 길어져 이번 글에서는 Github Actions의 개념과 yml 파일에 대하여 알아보고자 한다.

게시글의 흐름은 필자가 해당 부분을 공부하고 적용하면서 찾아보았던 순서대로 작성해보았다.

---

우선,

Github Action을 사용하는 방법부터 알아보자.

 

Github Actions은 Github에 올라와있는 Repository에서 사용할 수 있기 때문에 테스트할 Repo를 생성해준다.

 

 

필자는 Dummy Repository를 생성하고, 이전에 사용했던 클린 아키텍처 예제 프로젝트를 넣어서 사용하였다.

프로젝트만 존재하면 되기 때문에, 별도의 프로젝트를 가져오지 않고 프로젝트를 생성만 해서 사용해도 무관하다.

 

Repository를 만들었으면, Actions 탭에 들어가면 된다.

위의 사진을 보면 Pull Requests 옆에 Actions 라는 탭이 보이는데, 이곳을 누르면 된다.

 

 

Actions 탭을 누르면 이처럼 다양하게 사용할 수 있는 Action들이 나오는데,

CI를 사용할 것이므로 우측에 보이는 Android CI 부분의 Configure를 누른다.

 

 

그러면 이처럼 .yml 파일을 생성하는 부분이 나오는데, 필자는 YML이라는 확장자를 처음 보았기 때문에 이것이 무엇인가? 라는 생각이 가장 처음 들었다.

 

그렇다면,

여기서 YML 이란 무엇인가?

사람이 쉽게 읽을 수 있는 데이터 직렬화 양식

 

위키에 따르면, YML은 이렇다고 한다.

.yml, .yaml을 확장자로 사용할수 있으며, 간단하게 생각하자면 JSON과 비슷하게 생긴 key-value 형태로 사용하는 마크업 언어라고 생각하고 넘어가도 무관할 것으로 보인다.

 

아무튼, 프로젝트의 workflows에 yml 형태로 파일을 생성하고,

yml 파일 내부에 자동으로 처리할 내용과 필요한 설정들을 작성해두어 CI/CD를 구현을 도와주는 파일이라고 보면 된다.

---

 

생성된 android.yml 파일을 보기 전에,

Github Action을 사용하기 위한 기본적인 개념을 확인하고 넘어가도록 하자.

 

Github Action에는 Workflow, Event, Job, Step, Action, Runner 등의 개념들이 존재하고, 앞서 기술한 6개에 대한 개념만 알고있어도 기본적인 세팅과 사용하는 것에는 큰 문제가 없을 것으로 보인다.

 

• Workflow
  • 자동화된 전체 프로세스. 최상위의 개념
  • 하나 이상의 Job으로 구성되어 있음.
  • Event에 의하여 예약되거나 트리거 될 수 있음.
  • YAML(YML) 파일로 작성되어 사용된다.
• Event
  • Workflow를 실행시키기 위한 특정 활동과 규칙을 말한다.
  • 기본적으로 사용하는 event는 다음과 같다.
    • 특정 branch에 push하거나 PR.
    • Git에서 특정한 작업을 수행
    • 정해진 시간에 수행.
• Job
  • 여러개의 Step으로 구성된다.
  • VM 환경에서 실행된다.
  • 병렬 실행로 수행될 수 있다.
• Step
  • Job에서 순차적으로 수행되는 프로세스 단위.
• Action
  • Workflow에서 가장 작은 단위.
  • Step 안에서 수행되는 독립적인 명령.
  • 커스텀하여 사용하거나 재사용, Marcketplace에서 가져와서 사용 등이 가능하다.
• Runner
  • Workflow가 실행 될 인스턴스.

 

각 개념별로 모든 설명을 작성한것은 아니고, 도입 단계에서 알고있으면 좋다 싶은 것들만 작성해 보았다.

사실 이렇게 작성해도 결과적으로 yml 작성에 필요한 것들만 자세하게 기억하면 되지 않을까 싶다.

---

이제 기본으로 생성된 yml 파일을 확인해 보자.

name: Android CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: set up JDK 11
      uses: actions/setup-java@v2
      with:
        java-version: '11'
        distribution: 'temurin'
        cache: gradle

    - name: Grant execute permission for gradlew
      run: chmod +x gradlew
    - name: Build with Gradle
      run: ./gradlew build

 

설명했던 기본적인 개념에 포함된 것들이 보일 것이다.

 

우선, 한 부분씩 확인을 해보자.

 

name: Android CI

 

보이는 그대로, 해당 yml 파일의 이름이라고 생각하면 된다.

이곳에 설정된 이름으로 Actions 탭의 workflows 항목에서 확인이 가능하다.

 

 

이런식으로 말이다.

 

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

 

on이라고 선언한 부분이 위에서 설명한 Event에 대해서 작성하는 부분이다.

Event는 workflow를 실행시키기 위한 트리거의 역할을 한다고 했던것을 기억하고 다시 확인해보자.

 

push와 pull_request가 작성되어있고, branches는 main으로 적혀있다.

즉, main으로 push나 pr 이벤트가 발생했을 때를 workflow를 실행시키는 트리거로 사용하겠다.

가 되는 것이다.

 

여기서 push나 pr의 조건은 여러개의 브랜치를 넣을 수 있고, 브랜치 대신 Tag를 조건으로 걸수 있는 등 다양하게 커스텀이 가능하니 필요한 조건이 있으면 공식 문서를 확인해보면 될 것 같다.

 

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: set up JDK 11
      uses: actions/setup-java@v2
      with:
        java-version: '11'
        distribution: 'temurin'
        cache: gradle

    - name: Grant execute permission for gradlew
      run: chmod +x gradlew
    - name: Build with Gradle
      run: ./gradlew build

 

이번에는 구문이 좀 길다.

가장 위에 jobs: 로 선언되어 있는것을 보니, 해당 부분이 Job에 대한 구문을 작성해둔 것으로 보인다.

 

Job은 여러개의 step으로 구성되어있으며 VM 환경에서 실행 될 작업들을 의미한다.라는 것을 생각하고 다시 구문을 보자.

 

runs-on 부분을 보자.

ubuntu라고 되어있는 부분은, 말 그대로 ubuntu에서 실행된다. 라는 의미가 되겠다.

ubuntu 외에도 macos, windows로 변경하여 Job이 실행 될 OS를 변경할 수 있다.

접미어인 -lastest 는 제공하는 OS의 가장 최신 버전을 말하는 것이고, 해당 접미어를 제거하고 제공하는 원하는 os의 버전을 붙여서 사용할 수 있다.

 

step 부분을 확인해보자.

Step은 job에서 순차적으로 수행되는 프로세스의 단위라고 하였다.

그리고 아래 항목들을 확인해보니 하이푼(-)으로 항목들이 구분되어있는 것을 볼 수 있다.

즉, 하이푼(-)을 통해 구분되어 작성되어 있는 항목들이 Step 구문에 작성되어 있는 Job에서 수행되는 프로세스들이라고 볼 수 있다.

Step 구문에서 사용되는 키워드는 uses, name, run, with 4가지가 보인다.

각 키워드에 대하여 알아보자.

• Uses: 해당 Step에서 수행할 Action을 말한다.
• name: 해당 Step의 이름을 말한다.
• run: 해당 Step에서 실행될 커맨드 라인을 말한다.
• with: 해당 Step에서 수행되는 Action에 정의되는 Parameter. Key-Value 형태이다.

기본적으로 작성되는 yml에는 4가지 키워드를 사용하여 step이 작성되어 있는데, 이것들 외에도 더 많은 옵션을 설정할 수 있는 키워드들이 있으니 필요할 떄 찾아보길 바란다.

 

 

모든 구문에 대해 설명해 보았다.

다시 처음으로 돌아가, 기본으로 작성된 yml 파일을 해석해보자.

 

Android CI 라는 이름을 가지고있는 workflow의 작업이다.

해당 파일이 실행되기 위한 트리거는

• Main 브랜치로 Push
• Main 브랜치로 PR

이 이루어졌을 때 실행된다.

 

workflow가 실행되게 되면,

• 가장 최신 버전의 ubuntu 환경에서 실행된다.

해당 환경에서 수행되는 작업들은

• actions/checkout@v2 : 소스코드를 가져온다.
• actions/setup-java@v2 : 작업을 수행하기 위한 JDK를 설정한다.
• chmod +x gradlew 라는 명령어를 shell에서 수행한다.
• ./gradlew build 라는 명령어를 shell에서 수행한다.

---

보통 다른 블로그의 글을 확인해보면, 이런식으로 자동으로 생성해주는 yml만 추가하고 실행을 시키면 된다고 한다.

 

그래서 필자도 기본으로 생성해주는 android.yml을 생성하고 commit을 실행해 주었다.

Commit은 가장 우측에 초록색 버튼으로 보이는 Start Commit을 누르면 된다.

 

 

상단에는 title, 하단에는 description이 들어가면 되는데, 커밋했을 때 가장 상단에 보이는 라인이 title쪽, 그 하단에 나오는게 description으로 Actions 탭에서 확인할 수 있는 Workflows에서는 Title만 확인이 가능하니 Title을 직관적으로 알 수 있도록 커밋 메세지를 작성하는 것이 좋다.

 

하단에 바로 작업한 브랜치에 commit 이 되는 것이 있고,

별도로 브랜치를 생성하여 PR을 생성하는 방법이 있다.

 

 

하지만 필자는 테스트용으로 dummy Repository로 사용하기 때문에 별도로 브랜치는 사용하지 않고 main에 바로 커밋하였지만, 실 적용이라면 브랜치를 새로 생성해서 작업하는 것이 좋을 것으로 보인다.

 

Commit이 완료되면, 다시 Actions 탭에 들어가서 확인해 보면 Workflows에서 다음과 같이 확인이 가능하다.

 

 

필자는 테스트를 하느라 기본 name인 Android CI를 가진 workflow가 여러개 만들었기 때문에 저렇게 나오는 것이고, 처음 적용했다면 Android CI는 한개만 보일 것이다.

 

그리고 우측에 보면 Title로 작성한 Commit이 보이게 되고, 노란색으로 뜨면서 yml에 작성했던 로직들이 수행되고 있음을 알 수 있다.

여기서, yml에 main에 커밋하는 것이 트리거로 작성해두었기 때문에 이 상태에서 다른 소스코드 커밋을 하게 되면 동일하게 Actions에서 해당 workflow가 실행되는 것을 확인할 수 있을 것이다.

 

 

자, 다른 블로그를 보면 여기서 정상적으로 성공해서 "이렇게 사용하면 됩니다." 라고 글을 끝냈겠지만,

필자는 이상하게 천천히 따라해도 한번에 정상적으로 되는 경우가 드문것으로 보인다.

역시나

정상적으로 실행되지 않았다.

 

필자는 여기서 해당 문제를 해결하기 위해서 생각보다 많은 시간을 투자하게 되었는데..

게시글이 생각보다 많이 길어지는 바람에, 해당 문제를 해결하는 과정에 대해서는 다음 글에 이어서 작성하도록 하겠다.