| [[GitHub| | ||
| {{{#!wiki style="min-height: calc(1.5em + 5px); margin: 0 -10px -5px" {{{#!folding [ 펼치기 · 접기 ] {{{#!wiki style="margin: -5px -1px -11px" | <colbgcolor=#000,#000><colcolor=#fff,#fff> 관련 인물 | 톰 프레스턴 워너 |
| 서비스 | 저장소 · GitHub Pages · GitHub Action · GitHub Packages · GitHub Wiki · GitHub Gist · GitHub Copilot | |
| 클라이언트 | GitHub CLI · GitHub Desktop · GitHub Mobile | |
| 오픈 소스 | Electron · Atom · Linguist · Tree-sitter | |
| 관련 문서 | 사건 사고 · GitHub Universe · npm | |
1. 개요
GitHub의 CI/CD 자동화 서비스.2. 구조
각각의 액션은 워크플로우라는 가장 큰 단위로 구성되며, 저장소의
.github/workflows 폴더 아래에 각 워크플로우를 정의하는 YAML 파일을 작성해 생성할 수 있다.하나의 워크플로우는 여러 job으로 구성되는데, 보통 하나의 job만을 가지지만 크로스 컴파일을 위해 matrix를 사용하는 경우 등 여러 job을 가지는 것도 가능하다. 하나의 job은 하나의 가상 머신 안에서 끝까지 순차적으로 실행되는데, 이 머신을 runner라고 한다. runner의 환경 설정 또한 워크플로우에서 정의 가능하기 때문에, 필요한 러너를 정의하고 원하는 job들을 특정 러너에 배치하는 것이 가능하다. 일례로 상술한 바와 같이 크로스 컴파일이 가능한 CD 환경을 구축한다면, x86와 ARM 두 아키텍처의 러너 R1과 R2를 정의한 다음, 지정된 환경에서 빌드를 수행하는 잡 J1과 J2를 만들어 알맞은 러너에서 돌릴 수 있다.
각각의 job은 또다시 여러 스텝으로 나누어지는데, 각각의 스텝은 '이 외부 액션을 사용해라(
uses)', '이 셸 스크립트를 실행해라(run)' 등 개별 action에서 실행할 수 있는 최소 실행 단위이다. job에 정의된 각각의 스텝은 mutable하게 반드시 순차적으로 실행되기 때문에 side-effect를 마음껏 누릴 수 있다. 가령 이전 스텝에서 빌드를 수행하고, 다음 스텝에서 빌드된 결과물을 사용해 테스트를 수행한 다음, 마지막 스텝에서 배포를 하는 것이 명시적 종속성 없이도 가능하다. 모든 스텝이 완료되면 해당 job은 종료된다.자주 사용되는 워크플로우를 사전에 설정하여
action.yml과 함께 패키징한 형태를 action이라 하며, 다른 액션에서 uses: 문법으로 불러와 재사용이 가능하다. 이때 스텝에서 with: 문법으로 액션 사이에 인자를 주고받거나 실행 결과를 환경변수에 담아 후속 스텝에서 steps.<스텝ID>.outputs.<키> 형태로 참조하는 것도 가능하다.3. 이벤트
모든 이벤트 종류 보기해당 워크플로우가 설치된 저장소에서 특정 상황이 일어날 때마다 해당 워크플로우를 자동으로 시작시키도록 정의할 수 있다. 수많은 이벤트가 있지만 대부분 CI 목적을 위해
push 등을 사용한다.모든 커밋 push에 대해 실행하려면
on:
pushdeploy 브랜치로 푸시되었을 때 CD를 수행하는 액션을 작성한다면on:
push:
branches:
- deployon:
push:
tags:
- v*.*.*cron trigger도 자주 쓰이는데 가령
on:
schedule:
- cron: 0 21 * * *액션을 수동으로 실행하고 싶은 경우, 리스닝할 이벤트 목록에
workflow_dispatch를 추가하면 해당 워크플로우 탭 UI에 해당 액션을 수동으로 실행할 수 있는 버튼이 생겨난다.웹 UI의 저장소 액션 탭에서 특정 이벤트 유형에 따라 필터링하는 것도 가능하다.
4. 특징
- GitHub 저장소와 직접적으로 연동된다. 해당 저장소의 다양한 이벤트에 반응해 자동으로 트리거되는 것은 물론이고 대부분의 경우 actions/checkout 등을 사용해 해당 저장소의 실제 코드를 상대로 작업을 수행한다.
- IaaC 원칙과 비슷하게 워크플로우 정의 형식으로 YAML을 사용한다.
- 타 사용자가 개발하고 배포한 액션을 마켓플레이스에서 쉽게 조회할 수 있다.
- 사용자 정의 액션은 JavaScript 또는 Docker로 배포할 수 있는데,[1] 대부분의 action이 JS를 사용한다. 이때 깃헙 API와의 상호작용을 위해 actions/toolkit을 임포트하는 편인데, 이 경우 상식적으로
node_modules를 저장소에 올릴 수 없기 때문에#100 별도의 번들러를 사용해 dist를 소스에 박아넣는다(...). 사이드 브랜치로 뺀다고 해도 결국 저장소에 올라는 간다.#
5. 기타
- 공개 저장소의 경우
github.com/<ORG>/<REPO>/actions/workflows/<WORKFLOW>.yml/badge.svg경로에서 해당 워크플로우의 실행 상태를 shields.io 스타일의 뱃지로 렌더할 수 있다.# 비공개 저장소도 만들 수 있지만, 해당 주소 접근시 GitHub 인증된 상태의 쿠키를 들고 있어야 한다. - act를 사용해 액션을 로컬에서 테스트해 볼 수 있다.