GitHub Actions

GitHub Actions 는 저장소에 일이 생기면 미리 정해 둔 작업을 대신 돌려 줍니다. 코드를 올리면 빌드와 테스트가 저절로 돕니다. 그 결과는 저장소 화면에 붙습니다. 무엇을 언제 돌릴지는 저장소 안에 파일로 적어 둡니다.

상세

GitHub Actions 는 GitHub 저장소에 딸려 있는 자동화 기능입니다. 빌드와 테스트를 사람이 손으로 돌리면 바쁠 때는 건너뜁니다. 깨진 코드는 합쳐진 뒤에야 문제가 드러납니다. GitHub Actions 는 그 일을 저장소가 맡아 돌리게 만듭니다.

이 절은 무엇이 작업을 깨우는지 봅니다. 그 다음 깨어난 작업이 어느 컴퓨터에서 어떤 순서로 도는지를 설정 파일 한 벌로 따라갑니다.

작업을 깨우는 사건

깃허브는 저장소에서 벌어지는 일을 하나하나 사건으로 다룹니다. 누가 푸시를 했다, 풀 리퀘스트가 열렸다, 이슈에 댓글이 달렸다 같은 것입니다.

이 사건 가운데 무엇이 작업을 깨울지를 골라 적어 둡니다. 이렇게 작업을 깨우는 조건을 트리거라고 부릅니다.

시각으로도 깨울 수 있습니다. 매일 정해진 시각에 돌게 걸어 두거나, 사람이 저장소 화면에서 버튼을 눌러 직접 돌립니다.

워크플로 · 잡 · 스텝

한 사건에 묶인 작업 전체를 워크플로라고 부릅니다. 「푸시가 오면 이것들을 한다」가 워크플로 하나입니다.

워크플로 안은 잡으로 나뉩니다. 잡 하나가 컴퓨터 한 대를 받습니다. 테스트 잡과 빌드 잡을 따로 두면 두 대에서 동시에 돕니다.

잡 안은 다시 스텝으로 나뉩니다. 스텝 하나는 명령 한 줄이거나 남이 만들어 둔 작업 한 벌입니다. 스텝은 적은 순서대로 돕니다. 하나가 실패하면 그 잡은 거기서 멈춥니다.

flowchart TD
    E["사건 · 푸시 · 풀 리퀘스트"] --> W["워크플로"]
    W --> J1["잡 · 테스트"]
    W --> J2["잡 · 빌드"]
    J1 --> S1["스텝 · 코드 내려받기"]
    S1 --> S2["스텝 · 테스트 돌리기"]
    J2 --> S3["스텝 · 코드 내려받기"]
    S3 --> S4["스텝 · 빌드하기"]

두 잡이 갈라지는 대목이 컴퓨터가 둘로 나뉘는 대목입니다. 그 아래로 내려가는 스텝은 각자의 컴퓨터 안에서 위에서 아래로 한 줄씩 돕니다.

저장소 안에 두는 워크플로 파일

워크플로는 .github/workflows/ 폴더에 파일로 적습니다. YAML(YAML Ain't Markup Language) 형식을 씁니다. 들여쓰기로 계층을 나타내는 설정 파일 형식입니다.

가장 작은 워크플로 한 벌은 이렇습니다.

on: [push]              # 푸시가 오면 돈다
jobs:
  test:
    runs-on: ubuntu-latest   # 리눅스 기계
    steps:
      - uses: actions/checkout@v4
      - run: npm test        # 테스트를 돌린다

on: 이 트리거입니다. jobs: 아래가 잡입니다. test 는 그 잡에 붙인 이름입니다. runs-on: 은 어떤 컴퓨터를 받을지 고르는 줄입니다. steps: 아래 두 줄이 그 컴퓨터에서 차례로 도는 스텝입니다.

그 두 줄 가운데 uses: 는 남이 만들어 둔 작업을 가져다 쓰는 줄입니다. 아래 「가져다 쓰는 액션」에서 다룹니다.

이 파일은 코드와 같은 저장소에 들어갑니다. 그래서 설정을 고친 것도 커밋으로 남습니다. 브랜치마다 다른 설정을 둘 수 있습니다.

잡마다 새로 받는 러너

러너는 잡을 받아 돌리는 컴퓨터입니다. 깃허브가 내주는 러너는 잡이 시작될 때 새로 만들어집니다. 잡이 끝나면 버려집니다.

sequenceDiagram
    participant 개발자
    participant 깃허브
    participant 러너
    개발자->>깃허브: 커밋을 푸시한다
    깃허브->>깃허브: 워크플로 파일을 읽는다
    깃허브->>러너: 잡을 하나 맡긴다
    러너->>깃허브: 저장소 코드를 내려받는다
    러너->>러너: 스텝을 차례로 돌린다
    러너->>깃허브: 기록과 성공·실패를 보고한다
    Note over 깃허브,러너: 잡이 끝나면 러너는 버려진다

그림의 마지막 줄이 개발자가 보는 것을 만듭니다. 풀 리퀘스트 화면에 붙는 초록 표시와 빨간 표시가 러너가 보고한 성공·실패입니다.

러너가 버려진다는 것은 앞 잡이 만든 파일이 다음 잡에 안 남는다는 뜻입니다. 빌드 결과를 다음 잡에 넘기려면 아티팩트로 올려 두고 받아야 합니다.

같은 이유로 내려받은 라이브러리도 잡마다 다시 받게 됩니다. 이것이 아까우면 의존성 캐시에 맡깁니다.

회사 안에서만 닿는 서버에 배포해야 하거나 특별한 장비가 필요할 때도 있습니다. 그때는 러너를 자기 컴퓨터에 직접 설치해 띄웁니다. 이렇게 띄운 것이 셀프 호스티드 러너입니다.

가져다 쓰는 액션

스텝 가운데 uses: 로 적는 것이 액션입니다. 액션은 자주 하는 일을 묶어 둔 단계 묶음입니다. 앞에서 말한 워크플로가 아니라 스텝 하나에 들어가는 묶음입니다. GitHub Actions 라는 이름도 여기서 나왔습니다.

코드를 내려받는 일은 어느 저장소에나 필요합니다. 그래서 위 예의 actions/checkout 처럼 이미 만들어져 공개된 액션을 이름으로 부르기만 하면 됩니다.

액션을 쓴다는 것은 남이 만든 코드가 내 저장소 안에서 도는 것입니다. actions/checkout@v4 처럼 이름 뒤 @ 다음에 붙는 것이 그 액션의 판입니다. 판을 안 적어 두면 그 코드가 바뀌었을 때 내 워크플로가 함께 바뀝니다.

코드 밖에 두는 비밀 값

배포하는 워크플로에는 대개 액세스 토큰이나 비밀번호가 필요합니다. 이런 값을 워크플로 파일에 적으면 저장소를 읽는 누구나 보게 됩니다.

그래서 비밀 값은 저장소 설정에 따로 저장해 두고 워크플로에서는 이름으로만 부릅니다. 이렇게 비밀 값을 코드와 떼어 두고 필요한 곳에만 넘기는 일을 시크릿 관리라고 합니다.

GitHub Actions 에 묶이는 대가

작업이 깃허브 위에서 도는 만큼 이 서비스에 묶입니다. 깃허브가 멈추면 빌드도 배포도 함께 멈춥니다. 저장소를 다른 서비스로 옮길 때 워크플로 파일은 못 가져갑니다. 워크플로 파일 형식이 깃허브 전용이기 때문입니다.

러너가 붐비면 잡이 줄을 섭니다. 내 코드에 문제가 없어도 결과를 기다리는 시간이 늘어납니다.

돌려 보기 전에는 설정이 맞는지 알기 어렵습니다. 파일을 고쳐 푸시해야 도는 구조라 설정 한 줄을 고치려고 커밋을 여러 번 쌓게 됩니다.

비공개 저장소는 러너가 돈 시간만큼 값이 매겨집니다. 잡을 잘게 쪼개 동시에 돌리면 기다리는 시간이 줄어듭니다. 대신 값이 늘어납니다.

저장소를 깃허브에 두지 않았다면 GitHub Actions 는 쓸 수 없습니다. 그때는 그 서비스가 가진 같은 기능을 쓰거나, 자기 서버에 따로 띄우는 도구를 씁니다.

관련 항목

GitHub Actions 가 일을 나누는 실행 단위

워크플로 · 잡 · 스텝 · 액션 · 러너 · 매트릭스 빌드

워크플로를 깨우는 사건과 조건

트리거 · 이벤트 · 푸시 · 풀 리퀘스트 · 브랜치 · 태그 · 크론 · 웹훅

워크플로 파일에 적히는 형식과 값

YAML · 환경 변수 · 시크릿 관리 · 액세스 토큰 · 설정 파일

잡과 잡 사이에 결과를 넘기는 저장 수단

아티팩트 · 아티팩트 저장소 · 의존성 캐시 · 캐시 키 · 컨테이너 이미지

러너가 작업을 돌릴 때 올라타는 실행 환경

컨테이너 · Docker · 가상 머신 · 컨테이너 런타임 · 셀프 호스티드 러너 · 리눅스

GitHub Actions 가 대신 굴려 주는 개발 관행

지속적 통합 · 지속적 배포 · 지속적 전달 · 파이프라인 · 자동화 · 커밋에서 배포까지 · 빌드 · 테스트 자동화

같은 역할을 두고 겨루는 자동화 도구

Jenkins · GitLab CI · CircleCI · Travis CI · Argo CD · Tekton · Drone

GitHub Actions 가 붙어 있는 저장소와 그 위의 협업 기능

GitHub · 저장소 · 원격 저장소 · 이슈 · 코드 리뷰