Skip to content

워크플로와 이벤트

개요

"코드를 push하면 자동으로 검사하고 빌드하자" 같은 규칙을 어디에, 어떻게 적어 두느냐가 CI/CD의 출발점이에요. GitHub Actions에서는 이 규칙을 워크플로(Workflow)라는 YAML 파일로, 저장소의 .github/workflows/ 아래에 선언해요. 워크플로는 어떤 이벤트에서 실행될지를 정하고, 그때 수행할 작업들을 나열해요.

상위 문서: GitHub Actions · 액션 · 러너

핵심 개념

워크플로 구성. 워크플로는 name, on(실행 트리거), jobs(작업 목록)으로 이뤄져요. .github/workflows 아래에 YAML 파일을 두면 GitHub이 자동으로 인식해요.

name: build
on:
  push:
    branches: [main]
  pull_request:
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run build

이벤트(on). 워크플로가 언제 실행될지는 on으로 정해요. 대표적인 게 push, pull_request예요. 브랜치 필터(branches:), 경로 필터(paths:)를 쓰면 특정 변경에만 돌도록 좁힐 수 있어요. 수동 실행을 원하면 workflow_dispatch를 함께 넣어요.

잡(Job)과 스텝(Step). 워크플로는 여러 잡으로 나뉘고, 잡은 여러 스텝으로 이뤄져요. 잡은 needs:로 서로 의존성을 선언할 수 있고, 각 잡은 별도의 러너에서 돌아가요. 스텝은 uses:(남이 만든 액션 재사용) 또는 run:(직접 명령 실행)으로 써요.

표현식과 컨텍스트. ${{ }} 안에서 표현식을 쓸 수 있어요. 예를 들어 ${{ secrets.X }}, ${{ github.sha }}처럼 GitHub이 제공하는 컨텍스트 값을 참조할 수 있어요. 이 값들은 잡이나 스텝의 동작을 조건별로 다르게 할 때 유용해요.

이벤트 트리거 시 주의점. pull_request 이벤트는 PR 생성·업데이트 시 돌지만, 커밋을 푸시한 브랜치가 아니라 머지 대상 브랜치(베이스) 기준으로 다른 컨텍스트(github.head_ref 등)를 써요. 또 on 키워드 문법이 실행 트리거만 다루는지 확인해야 해요. 워크플로 디버깅은 Actions 탭에서 실행 로그를 보는 것으로 시작해요.

실제 적용(데이터스케쳐스)

저장소에 push되면 build 워크플로가 체크아웃 → 테스트 → 이미지 빌드 → Harbor push까지 이어서 처리해요. PR에 대해서는 별도 워크플로로 lint·테스트만 돌려, 머지 전에 문제를 잡아요. 각 워크플로가 끝나면 그다음 배포 반영은 ArgoCD가 맡아요. 워크플로를 나눌 때는 한 파일에 너무 많은 일을 담지 말고, 목적별로(빌드·테스트·릴리스) 파일을 나누는 게 다루기 좋아요.

더 알아보기