1. 코드 변경 및 협업 이벤트 트리거 (Webhook Events)
저장소(Repository) 내에서 발생하는 깃(Git) 작업이나 협업 활동을 감지하여 실행되는 가장 기본적인 트리거 유형입니다.
① push
- 지정한 브랜치나 태그에 새로운 커밋이 푸시될 때 워크플로우를 실행합니다. 특정 파일 경로(
paths)를 지정해 필터링할 수도 있습니다. - 적합한 CI/CD 시나리오
- CI: 개발 브랜치(
feature/*)에 코드가 푸시될 때마다 자동으로 빌드 및 단위 테스트(Unit Test)를 수행하여 코드 안정성을 상시 검증할 때 적합합니다. - CD:
main또는master브랜치에 코드가 병합(Push)되는 즉시 운영 환경(Production)이나 스테이징 환경에 자동으로 패키징 및 배포를 진행할 때 사용합니다.
- CI: 개발 브랜치(
② pull_request
- 풀 리퀘스트가 생성(
opened), 수정(edited), 또는 대상 브랜치로 병합되기 전 동기화(synchronize)될 때 실행됩니다. - 코드 리뷰 및 품질 게이트(Quality Gate): 코드 리뷰어가 승인하기 전, 코드 스타일(Lint), 정적 분석(SonarQube 등), 통합 테스트를 강제하여 결함이 있는 코드가 메인 브랜치에 합쳐지는 것을 방지할 때 필수적으로 사용됩니다.
③ release
- 설명: GitHub 저장소에서 새로운 릴리즈(Release) 버전을 생성하거나 배포판을 발행할 때 실행됩니다.
- 정식 배포판 및 패키지 발행:
v1.0.0과 같은 태그 기반의 정식 버전을 릴리즈할 때, Docker Hub나 npm, Maven Central 같은 외부 패키지 저장소에 라이브러리 및 이미지를 빌드하여 업로드하는 마스터 배포 파이프라인에 적합합니다.
2. 수동 및 외부 연동 트리거 (Manual & Custom Events)
자동화된 이벤트 외에, 관리자가 직접 개입하거나 외부 인프라 시스템과 연동해야 할 때 사용하는 트리거 유형입니다.
① workflow_dispatch
- GitHub 웹 UI 콘솔에서 사용자가 직접 버튼을 눌러 워크플로우를 실행합니다. 실행 시점에 사용자로부터 커스텀 입력값(
inputs, 예: 배포 환경 선택, 버전 명시)을 받아 변수로 활용할 수 있습니다. - 선택적 배포 및 롤백: 테스트 환경(
dev,staging)에 개발자가 원할 때만 수동으로 코드를 밀어 넣거나, 운영 장애 시 특정 이전 버전으로 즉시 롤백 워크플로우를 수동 구동해야 하는 상황에 적합합니다.
② repository_dispatch
- GitHub 외부 시스템에서 GitHub REST API를 호출하여 워크플로우를 원격으로 강제 실행하는 웹훅 트리거입니다.
- 타 시스템 연동 웹훅: 사내 전용 레거시 빌드 서버, 외부 모니터링 시스템(Datadog 등)에서 알림이나 특정 이벤트가 발생했을 때 GitHub Actions 파이프라인을 유기적으로 연동하여 구동하고 싶을 때 사용합니다.
3. 시간 기반 트리거 (Scheduled Events)
인간의 개입이나 코드 변경과 무관하게, 사전에 정의된 특정 시간에 주기적으로 실행되는 트리거 유형입니다.
① schedule
- 리눅스의 크론탭(
cron) 표현식을 사용하여 분, 시, 일, 월, 요일 단위로 주기를 지정해 워크플로우를 정기적으로 실행합니다. - 야간 배치 및 무거운 테스트: 매일 새벽 2시처럼 사용자가 적은 시간에 전체 시스템을 무겁게 돌리는 종단간(E2E) 테스트나 보안 취약점 스캐닝을 수행할 때 적합합니다.
- 정기 백업 및 데이터 동기화: 매주 주말마다 개발 데이터베이스의 스냅샷을 백업하거나, 외부 데이터 API를 파싱하여 저장소를 업데이트하는 정기 자동화 작업에 활용됩니다.
4. 워크플로우 연동 트리거 (Workflow Chaining)
파이프라인이 거대해지거나 마이크로서비스 아키텍처(MSA) 환경에서 여러 워크플로우 간의 의존성을 제어할 때 사용하는 유형입니다.
① workflow_run
- 동일 저장소 내의 다른 특정 워크플로우가 실행을 시작했거나 성공적으로 완료(
completed)되었을 때 이를 감지하여 연속적으로 실행됩니다. - 순차적 파이프라인 빌드: '코드 빌드 및 단위 테스트' 워크플로우가 완전히 성공한 직후에만 '보안 스캔 및 인프라 배포' 워크플로우를 이어서 실행하도록 파이프라인을 분리하여 자원을 효율적으로 관리할 때 적합합니다.
