안녕하세요, 로빈입니다!
Github Actions
Github Actions 란?
💡 Github 에서 제공하는 자동화 도구다. CI/CD 나 Github의 여러 서비스를 자동화하는데 사용할 수 있다.가령, 이슈가 생성되면 이에 대응되는 브랜치를 만들거나, 특정 브랜치에 커밋이 발생하면 테스트가 동작하고, 그 결과를 메신저를 통해 전달하는 등의 작업을 할 수 있다.
Github Actions가 아니더라도 여러 CI / CD 도구들이 있지만, Github에서 직접 제공하는 기능인 만큼 자동화 설정들을 모두 Github에서 관리할 수 있고, 여러 오픈 소스를 사용할 수 있다는 장점이 있다.
아래 공식 자습서를 통해 학습할 수 있다.
GitHub Actions 이해 - GitHub Docs
Github Actions의 구성 요소
Events
💡 자동화를 트리거하는 여러 상황을 말한다. push, pr 생성, 이슈 생성 등 대부분 Github의 여러 서비스의 자연스러운 상황이 Events에 해당한다.아래 문서에서 여러 이벤트의 종류를 알 수 있다.
이벤트 중에는 세부적인 타입을 지정할 수 있는 경우도 있다. 위 문서에서 ‘활동 유형’ 으로 번역된 것이 타입이다.
Workflow
💡 [Events](https://www.notion.so/Events-a1abfc629fb74895a185c22736a49e92?pvs=21) 가 발생할 때 실행되는 하나의 작업 흐름을 말한다. 보통, 하나의 `.yml` 파일로 정의한다.작업 흐름을 의미하는 workflow 의미 그대로, 커다란 작업의 흐름을 표현한다. 예를 들어, “백엔드 CI”는 하나의 workflow로 표현하는 것이 적절하다.
하나의 workflow는 하나 이상의 job으로 구성된다.
Job
💡 workflow 를 구성하는 단일 작업이다. 하나의 runner 에서 실행될 수 있는 중간 크기의 작업이다.runner 는 후술하겠지만 하나의 운영체제가 포함된 컨테이너를 말한다. 즉, 하나의 컴퓨터 위에서 돌아갈 수 있는 작업을 말한다. 여러 Job은 기본적으로 병렬로 처리된다. Job 사이에 실행 순서가 명시한다면, Job 사이의 실행 순서를 제어할 수 있다.
하나의 Job은 하나 이상의 step으로 구성된다.
step
💡 가장 작은 작업의 단위이다. 하나의 step에서 오픈소스로 제공되는 기능을 사용하거나, 복수의 쉘 명령어를 실행할 수 있다.예를 들어 CI 작업을 위해 Github의 코드를 pull 해오는 작업이나, Java 를 다운받고 몇가지 설정을 해주는 등의 작업은 오픈소스로 제공되고, 이를 가져와 실행할 수 있다.
curl 등의 쉘 명령어를 사용하여 특정 운영체제가 제공하는 여러 기능들을 사용할 수 있다. 당연히 쉘 스크립트, 파이썬 스크립트 등을 실행하는 것도 가능하다.
단, 하나의 스텝에서 오픈소스로 제공되는 기능과 쉘 명령어를 동시에 사용할 수는 없다.
runner
💡 Job이 실행되는 컨테이너다. 운영체제를 포함하고 있다.기본적으로 Github가 제공하는 runner를 사용해 윈도우, 리눅스, 맥 OS 등을 사용할 수 있다.
원한다면 직접 자체 서버를 runner로 사용할 수 있다. 이를 self-hosted runner 라고 부른다.
Github Actions 제어
여러 구성 요소를 작성하다보면, 일반적인 프로그래밍을 하는 것 처럼, 조건에 맞을 때에만 특정 요소를 실행하거나, 각 요소들 사이에 데이터를 전달하고 싶을 것이다. 이 단락에서는 이런 것을 다룬다.
식
💡 일반적인 프로그래밍 언어에서 제공하는 것 처럼 문자열, 숫자, 불리언 등의 타입과 비교 연산자, 몇가지 함수를 제공한다. 단, 매우 빈약하다는 점을 유의해야 한다.식은 ${{ 식 }} 형태로 사용한다. 보통, if 와 함께 조합하여 특정 조건을 설정하는 것으로 사용된다.
컨텍스트
💡 workflow, event , job, step 등 상술한 구성 요소들의 여러 정보를 모아둔 것이다. 컨텍스트는 객체이거나 문자열이다.${{ 컨텍스트 }} 형태로 사용한다. 식과 조합하여 사용할 수 있다. 예를 들어 ${{ github.workflow }} 는 워크플로우의 이름을 뜻한다.
말로 설명하는 것 보다 코드를 보거나 문서를 보는 것이 더 이해하기 쉬울 것이다.
같은 job에 속한 step 사이에 데이터 전달
컨텍스트를 사용하는 여러 예시 중 하나로 같은 job에 속한 step 사이에 데이터를 전달하는 방법에 대해 알아보자.
만약, 어떤 step 에서 이전 step 의 성공 여부를 알아야 한다고 하자. 이럴 때 문서 에 나온 것 처럼 steps 컨텍스트를 사용할 수 있다.
steps:
- name: step1
continue-on-error: true # step이 실패해도 다음 step 을 실행하는 설정
run: ls
- name : step2
if: ${{ steps.step1.outcome == 'success' }} # 특정 step의 결과를 담고있는 컨텍스트에 접근
run: echo "step1 success"종속 job 사이에 데이터 전달
컨텍스트를 사용하는 여러 예시 중, 종속 job 의 데이터를 표현하는 needs 컨텍스트를 사용하는 방법에 대해 알아보자.
만약, 종속 작업의 성공 여부를 알고 싶다고 하자. 이럴 때 문서에 나온 것 처럼 needs 컨텍스트를 사용할 수 있다.
name: Build and deploy
on: push
jobs:
build:
runs-on: ubuntu-latest
outputs: # 작업의 출력을 정의하는 부분
build_id: ${{ steps.build_step.outputs.build_id }} # 출력의 구분자가 build_id다.
# 특정 step 의 출력을 job의 출력으로 지정한다는 의미다.
steps:
- name: Build
id: build_step
run: echo "build_id=$RANDOM" >> $GITHUB_OUTPUT
# echo 명령어를 이용해 step의 출력을 지정한다. 출력의 구분자는 build_id 다.
deploy:
needs: build
runs-on: ubuntu-latest
steps:
- run: echo "Deploying build ${{ needs.build.outputs.build_id }}"
debug:
needs: [build, deploy]
runs-on: ubuntu-latest
if: ${{ failure() }}
steps:
- run: echo "Failed to build and deploy"
비밀 데이터
외부 API의 키값 등 스크립트에서 사용해야 하는 데이터지만, 보안상의 이유로 공개되어서는 안되는 정보들이 있다. 이러한 정보들을 각 레포지토리의 설정에서 값을 지정할 수 있고, secrets 라는 컨텍스트를 통해 접근할 수 있다.
예를 들어 ${{ secrets.BOT_TOKEN }} 는 레포지토리에 설정한 BOT_TOKEN 이라는 이름의 비밀 데이터에 접근하는 식이다.
