앞장에서 우리는 CI/CD 를 통해 hello world 를 찍어보면서 다양한 내용들 (언어보단 리눅스, 라이브러리의 존재 등) 을 확인하고 CI 의 이점도 새삼 확인해볼 수 있었다.
이제 지난번에 간략하게만 언급했던 on 과 job 에 대해서 다시 다루어보고 다음 단계로 넘어가보려 한다.
(사실 단원을 따로 두긴 했지만 그렇게 많은 내용을 다루진 않을 것 같다.)

1. on

on 에 대해서는 주로 Event 와 연결되어 많이 이야기가 나온다.
github 에서 이야기하는 Event 는 github Repository 내에서 동작하는 일련의 활동 (ex. pull Request, push 등) 을 통칭한다.

아래는 on 의 간단한 예이다.

on:
  push:
    branches:
      - '*'

위 내용을 그대로 해석하면 아래와 같다.

어떤 브랜치든 push 할때마다 github actions 를 실행시킨다.

이렇게 특정 Event 에 맞춰 github actions 을 실행해줄 수 있다.

사용 예 정리

사실 위 내용만 알면 끝났다.
우리는 다양한 Event 및 그 Event 의 조합 을 통해 다양한 케이스를 만들 수 있다.

1. tag push

on 은 태그 push 도 캐치할 수 있다.

on:
  push:
    tags:
      - 'test_*'

위 내용을 해석하면 아래와 같다.

test_ 문구로 시작되는 모든 문자열에 대응하는 모든 태그를 push 하는 경우에 github actions 를 동작시킨다.

2. 각종 Event 조합

이벤트를 조합하여 캐치도 가능하다.
: 를 통해 각 Event 를 구분시키며 언급된 event 들은 or 조건으로 동작한다.

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

위 내용을 해석하면 아래와 같다.

main 브랜치로 PR 이 올라오거나, main 으로 push 가 되는 경우 github actions 을 동작시킨다.

그 외에 다양한 내용(page 작성 등)을 캐치할 수 있고, ! 을 통해 특정 이벤트의 경우를 제외하는 등 다양한 처리가 가능하다. 자세한 내용은 공식 문서 참고를 해보는 걸 추천한다.

2. job

job 은 하나의 실행 작업 을 이야기한다.
위에서 이야기했던 "github actions 를 동작시킨다" 가 사실은 jobs 에 언급된 job 을 동작시킨다 와 같은 의미이다.

사용 예 정리

job 역시 위 내용만 알면 끝났다.
간단한 사용 예 하나를 언급해보려 한다.

병렬 처리

job 은 파일 내에 여러개를 만들 수 있다. (jobs 이름에서 일부 예상한 사람들도 있을 것이다.)
그러면 job 들을 분리 시켜 병렬로 실행할수도 있을까? 가능하다.

필자는 오늘 배운 것을 테스트해보기 위해
.github/workflows 디렉터리 내에 3_on_job 브랜치를 만들고
3_on_job.yaml 이라는 파일을 만들어 아래와 같이 작성하였다.

name: 3_on_job
   
on:
  push:
    branches: 
      - '3_*'
      - 'master'

  pull_request:
    branches:
      - 'master'

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: 'adopt'
        cache: gradle

    - name: Grant execute permission for gradlew
      run: chmod +x gradlew
    - name: Build with Gradle
      run: ./gradlew build
    - name: Print Hello World
      run: echo "3_*"

작성을 완료하면 최종적인 파일 구조는 이렇게 된다. 작성을 완료하면 어떤 동작이 일어날까?
바로 캡처는 못했지만 위의 push 조건으로 인해 job 이 동작하는 것을 확인할 수 있다.

그리고 master 로 PR 을 만들어보면 어떨까?

Android CI 로 적혀 있는 내용은 일전에 on 조건에 아래같이 적혀있어서 그렇다.

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

master 로 PR 또는 push 가 이루어질 때 캐치하므로, Android CI 도 동작한다.

우리는 이를 통해 하나의 디렉터리에 여러개의 yaml 파일을 둘 수 있고
이를 통해 여러개의 job 을 병렬로 실행시킬 수 있음을 확인할 수 있다.

이 외에 다양한 기능들 또한 존재한다.
자세한 내용은 공식 문서 참고를 해보는 걸 추천한다.

3. WorkFlow

위에서 짤막하게 언급했지만 jobs 에는 여러개의 job 을 등록할 수 있다.

jobs:
  my_first_job:
    name: My first job
  my_second_job:
    name: My second job

그러면 우리는 jobs 를 아우르는 파일 단위를 어떻게 부를까?
WorkFlow 라고 이야기한다.

아래 조건만 지킨다면 github repository 내에서, 하나의 workflow 로 인지된다.

1. repository 내 .github/workflows 디렉터리 내에 존재해야 한다.
2. .yml or .yaml 확장자를 가져야한다.

4. 결론

예상보다 한 파트 설명 하나가 늘었다 (workflow)

대략적인 큰 구조를 이해하는 시간이 있으면 좋겠다고 생각해서
한 단원을 할애해 정리해 보았는데 돌아보니 기초적인 내용만 언급하고,
공식 문서 참고하라는 말만 있어 조금 쑥스럽긴 하다.
(막상 정리해보려했는데 공식 문서 양이 너무 많기도 했다. ㅎㅎ)

하지만 공식 문서에 왠만한 내용과 사용 예는 나와있고,
막히는 내용들은 왠만해서 공식문서에 언급되어 있으므로
github actions 코드를 작성할 때, 공식 문서를 1순위로 참고하는 것을 추천한다.

다음장에선 오늘까지 다뤄본 내용을 기반으로 드디어 CI 코드를 작성해볼 예정이다.

참고

1. 공식 문서