GitHub Actions는 Github가 공식적으로 제공하는 빌드, 테스트 및 배포 파이프라인을 자동화할 수 있는 CI/CD 플랫폼이다.
레포지토리에서 Pull Request 나 push 같은 이벤트를 트리거로 GitHub 작업 워크플로(Workflow)를 구성할 수 있다. 워크플로는 하나 이상의 작업이 실행되는 자동화 프로세스로, 각 작업은 자체 가상 머신 또는 컨테이너 내부에서 실행된다.
워크플로는 .yml (혹은 .yaml ) 파일에 의해 구성되며, 테스트, 배포 등 기능에 따라 여러개의 워크플로도 만들 수 있다. 생성된 워크플로는 .github/workflows 디렉토리 이하에 위치한다.
비공개 레포지토리의 경우 Github Actions가 작동할 때의 용량과 시간이 제한되어있으며 공개 레포지토리는 무료로 사용 가능하다.
Yet Another Markup Language의 약자로, 사람이 읽을 수 있는 데이터 직렬화 언어를 의미한다. 여기서 YAML을 YAML ain’t markup language(재귀 약어)로 생각하는 사람도 있는데 이 경우에는 YAML이 문서가 아닌 데이터용임을 강조하는 말이라고 생각하면 된다. 파일로 작성시 확장자는 .yaml 혹은 .yml 확장자를 가진다.
YAML은 사람이 읽을 수 있고 이해하기 쉬워 프로그래밍 언어 중에서도 인기가 높다. 또한 다른 프로그래밍 언어와 함께 사용할 수도 았오 YAML은 그 유연성과 접근성으로 인해 자동화 프로세스를 생성하는 데에도 사용된다.
Github actions workflow 설정을 위해 작성된 YAML 파일 예시
name: # workflow 이름
# 언제 job을 작동시킬지
on: [push, pull_request]
# 어떤 job을 할지
jobs:
test: # 테스트 진행시 실행할 동작
runs-on: ubuntu-latest # 작업을 실행할 깃허브의 호스팅 러너
steps:
#실행할 작업/ 깃허브에 릴리즈된 특정 버전 참조
- uses: actions/checkout@v2
- name: Bare Minimum Requirements
uses: actions/setup-node@v1 #node 셋업
with:
node-version: '16' #node 버전 16
- run: npm install
- run: npm test
위의 YAML 파일을 보면 다른 형식의 파일과는 조금 다른 점이 눈에 보인다.
아래는 MDN의 JSON파일이다.
{
"squadName": "Super hero squad",
"homeTown": "Metro City",
"formed": 2016,
"secretBase": "Super tower",
"active": true,
"members": [
{
"name": "Molecule Man",
"age": 29,
"secretIdentity": "Dan Jukes",
"powers": [
"Radiation resistance",
"Turning tiny",
"Radiation blast"
]
}
]
}
JSON 파일과 YAML 파일은 key-value 형태로 작성된 파일이며, 계층 구조를 가지는 것에는 동일하다.
그러나 YAML 파일은 "" (큰따옴표, double quotation marks) 없이 문자열 작성이 가능해, 설정을 위한 스펙이나 프로퍼티 값 등이 JSON 파일에 비해 한 눈에 들어온다.
또한 JSON 파일처럼 {} 형태로 감싸줄 필요도 없기 때문에 스코프의 압박(잘못 쓰면 일일이 어디가 처음이고 끝인지 찾아야 하는 등)에서 벗어날 수도 있다.
게다가 YAML 파일은 JSON 파일과 다르게 주석을 작성할 수 있다. JSON 파일은 주석을 작성할 수 없기 때문에 해당 파일 하나만 두고 커뮤니케이션 하기가 까다롭지만, YAML 파일은 애초에 파일 내에 주석을 작성할 수 있기 때문에 커뮤니케이션 하기가 훨씬 수월하다.
그리고 YAML은 JSON의 상위 호환 격이므로, 기존 json문서를 그대로 yaml파일로 사용하거나 원하는 부분만 손볼 수 있고 반대로 yaml을 json으로 변환해 사용할 수도 있다는 점이 장점으로 작용한다.
YAML도 일종의 프로그래밍 언어이기 때문에 문법이 있다. 해당 문법을 지켜 작성하지 않으면 YAML 파일로 읽지 못하기 때문에, 문법을 잘 지켜줘야 한다.
#
: 주석
---
: 문서의 시작 (선택 사항)
...
: 문서의 끝 (선택 사항)
#이런 식으로 주석을 작성할 수 있습니다.
--- #문서 시작
#이 사이에 내용이 들어갑니다.
... #문서 끝
들여쓰기
: 들여쓰기는 기본적으로 2칸 또는 4칸을 지원한다. 보통 2칸씩 들여쓰는 것을 추천하며, 탭 키가 아닌 스페이스 키로 들여써야 한다.
key: value
이며, :
다음에는 무조건 공백 문자가 와야한다.
key: value
int
, string
, boolean
, 리스트, 매핑을 지원한다. 여기서 int
와 string
타입은 스칼라(Scalar)라 부르고, 배열 혹은 리스트는 시퀀스(Sequence)라 부른다. 매핑에는 기본 표현인 key-value 쌍 및 hash, dictionary가 포함된다.
#int(숫자)
int_type: 1
#string(문자열)
string_type: "1"
#blooean(참/거짓)
boolean_true_type: true
boolean_false_type: false
#이외에 yes, no로 작성하기도 합니다.
yaml_easy: yes
yaml_difficult: no
#리스트(배열 형태)
person:
name: Chungsub Kim
job: Developer
skills:
- docker
- kubernetes
# JSON 형식의 "skill" : [docker, kubernetes]와 같습니다.
객체 표현은 key 작성 후 두 칸을 들여써서 key-value 형태로 작성을 해주거나, key를 작성 후 중괄호({})로 한 번 묶고 key-value 형태로 작성한다.
key:
key: value
key: value
#또는 이렇게도 작성합니다. 가독성을 위해 사용합니다.
key: {
key: value,
key: value
}
줄바꿈 표현(|)과 줄바꿈 무시 표현(>)이 있다.
# |는 줄바꿈 표현입니다.
# JSON 형식의 "comment_line_break": "Hello codestates.\nIm kimcoding.\n"과 같습니다.
comment_line_break: |
Hello codestates.
Im kimcoding.
# >는 줄바꿈 무시 표현입니다.
# JSON 형식의 "comment_single_line": "Hello world my first coding."과 같습니다.
comment_single_line: >
Hello world
my first coding.
key-value 쌍에서 value에 :가 들어간 경우는 반드시 따옴표가 필요하다.
# error가 납니다.
windows_drive: c:
# 이렇게 써야 합니다.
windows_drive: "c:"
windows_drive: 'c:'
YAML은 일반적으로 설정 파일(configure file 등)에 사용하기에 좋다. 따라서 spring boot, github action 등 다양한 CI/CD 툴이나 프레임워크에서 사용되고 았다. YAML을 실제로 사용하고 있는 프레임워크 중 쿠버네티스 또한 대표적으로 뽑을 수 있다. 기본적인 팟, 레플리카, 디플로이먼트 등 모든 내부 오브젝트가 yml문서로 작성되어 있으며, yaml고유 기능 중 하나인 문서 스트림을 사용해 클러스터 전체의 설정을 파일 하나로 관리하기도 한다.