Github Action의 on 이벤트 종류
GitHub Actions의 on 키워드는 워크플로우가 언제(trigger) 실행될지를 정의함.
이 필드는 매우 유연하며 다양한 이벤트에 반응하도록 설정할 수 있음.
이벤트는 크게 GitHub 이벤트(push, pull_request 등), 배포/릴리스 이벤트(release, deployment, page_build 등), 이슈 관련 이벤트(issues, issue_comment 등), 워크플로우 자체 이벤트(workflow_dispatch, workflow_run 등)로 분류할 수 있음.
또한 schedule을 사용하면 정해진 시간 간격(CRON)으로 워크플로우를 실행할 수도 있음.
저장소의 기본 이벤트 (Commit, PR 관련 등)
1. push
1-1. 설명
저장소에 푸시가 발생했을 때 실행됨(브랜치, 태그 포함).
일반적으로 가장 많이 사용하는 이벤트 중 하나임.
1-2. 사용 예시
on:
push:
branches:
- main
- 'feature/*'
tags:
- 'v*.*.*'
branches: 특정 브랜치에만 반응하도록 설정할 수 있음.
tags: 태그가 푸시될 때만 반응하도록 설정할 수 있음.
1-3. 주의사항
포크(fork)에서 생성된 푸시 이벤트는 기본적으로 워크플로우가 실행되지 않음.
보안 이슈를 방지하기 위함임.
푸시 이벤트 내 HEAD 커밋에서만 이벤트 컨텍스트를 가져올 수 있음.
2. pull_request
2-1. 설명
Pull Request(이하 PR)가 열렸을 때, 변경되었을 때(커밋이 추가되거나 타겟 브랜치가 바뀌거나), re-open될 때, 혹은 PR이 동기화될 때(triggered by synchronizing)가 있을 때 실행됨.
2-2. 사용 예시
on:
pull_request:
types: [opened, reopened, synchronize]
branches:
- main
- 'release/*'
types로 세분화할 수 있음.
예를 들어, opened, closed, reopened, synchronize, edited, assigned 등이 있음.
특정 브랜치로의 PR에만 반응하도록 설정할 수도 있음.
2-3. 주의사항
PR 이벤트가 발생할 때는 github.event.pull_request 컨텍스트 안에 상세 정보가 담겨 있으므로 이를 적극 활용해 QA, 빌드, 테스트 등의 작업을 진행할 수 있음.
외부 기여(Fork PR)에 대한 보안 정책을 주의해야 함(특히 GitHub Actions의 시크릿 사용).
3. pull_request_target
3-1. 설명
pull_request_target 이벤트는 ‘대상 브랜치의 워크플로우’를 기준으로 실행된다는 점에서 pull_request 이벤트와 차이가 있음.
즉, PR이 온 저장소의 기본 브랜치나 워크플로우 파일이 존재하는 브랜치의 워크플로우 구성이 적용됨.
3-2. 사용 예시
on:
pull_request_target:
types: [opened, reopened, synchronize]
3-3. 주의사항
pull_request_target은 포크에서 온 PR에 대해서도 시크릿을 사용할 수 있게 만듬.
하지만 이는 보안상 주의가 필요하며, 외부 커밋이 실행 권한을 얻을 수 있으므로 민감한 정보를 다루는 일에는 신중해야 함.
pull_request_target의 컨텍스트는 PR의 head SHA를 체크아웃하지 않고, base 브랜치의 코드를 체크아웃한다는 점이 중요함.
4. create, delete
4-1. 설명
create: 브랜치나 태그가 새로 생성되었을 때 실행됨.
delete: 브랜치나 태그가 삭제되었을 때 실행됨.
4-2. 사용 예시
on:
create:
branches:
- 'feature/*'
tags:
- 'v*.*.*'
delete:
branches: [ 'hotfix/*' ]
4-3. 활용도
브랜치 생성 시 자동 초기 세팅 작업 등(예: 이슈 템플릿 자동 생성)을 할 수 있음.
브랜치 삭제 시 청소(clean-up) 작업, 자동 리소스 정리, 태그 삭제 후 후속 작업 등을 할 수 있음.
5. workflow_dispatch
5-1. 설명
사용자(또는 API)에 의해 수동으로 워크플로우를 실행(trigger)할 수 있는 이벤트임.
GitHub Actions UI에서 ‘Run workflow’ 버튼을 통해 인풋을 지정해 실행하는 방식임.
5-2. 사용 예시
on:
workflow_dispatch:
inputs:
environment:
description: 'Which environment to deploy to?'
required: true
default: 'staging'
version:
description: 'Version to deploy'
required: false
5-3. 활용도
테스트 또는 배포 등 임의 시점에 실행해야 하는 작업을 위한 수동 트리거임.
여러 입력값(inputs)을 받아서 조건에 따라 다른 스크립트를 실행하는 식으로 설계할 수 있음.
이슈 및 기타 GitHub 관리 이벤트
1. issues
1-1. 설명
이슈가 생성, 수정, 할당(assigned), 라벨 변경, 열림, 닫힘, 재오픈 등 다양한 액션(types)을 기준으로 트리거됨.
1-2. 사용 예시
on:
issues:
types: [opened, edited, assigned, closed]
1-3. 활용도
새 이슈 생성 시 메시지 자동 댓글, 라벨 자동 할당(예: triage) 등의 작업.
이슈가 닫힐 때 기록 자동화, 통계 집계, 외부 API 호출 등.
2. issue_comment
2-1. 설명
이슈 혹은 PR의 코멘트가 달릴 때(또는 수정, 삭제될 때) 실행됨.
2-2. 사용 예시
on:
issue_comment:
types: [created, edited, deleted]
2-3. 활용도
특정 명령어 형식의 댓글을 트리거로 작업 실행(“/deploy” 같은 챗옵스).
코멘트 내용 분석 후 자동 메타 정보 업데이트 또는 CI 재실행 등.
3. label
3-1. 설명
라벨(Label)이 생성, 삭제, 수정될 때 트리거됨.
3-2. 사용 예시
on:
label:
types: [created, deleted, edited]
3-3. 활용도
레이블 사용 현황을 추적하거나, 특정 레이블이 추가되면 다른 이슈/PR을 자동 업데이트함.
4. milestone
4-1. 설명
마일스톤이 생성, 열림, 닫힘, 편집 등 되었을 때 트리거됨.
4-2. 사용 예시
on:
milestone:
types: [created, closed]
4-3. 활용도
마일스톤이 닫힐 때 이슈 및 PR 상태 자동 업데이트, 배포 태그와 연결되는 작업 수행함.
5. project, project_card, project_column
5-1. 설명
GitHub Projects(프로젝트 보드) 관련 이벤트로, 프로젝트가 생성/업데이트/삭제되거나 프로젝트 카드/컬럼이 생성, 이동, 삭제되는 등 다양한 이벤트를 트리거로 사용할 수 있음.
5-2. 활용도
작업 보드에서 카드가 특정 컬럼으로 이동하면 자동 알림, 자동 태그 부여 등의 워크플로우.
배포, 릴리스, 빌드 관련 이벤트
1. release
1-1. 설명
릴리스가 생성, 수정, 게시, 취소, 삭제될 때 트리거됨.
1-2. 사용 예시
on:
release:
types: [published, created, edited]
1-3. 활용도
새 버전 릴리스 시 자동 빌드 & 배포 파이프라인 실행함.
릴리스 노트를 슬랙 등에 자동 게시됨.
2. deployment, deployment_status
2-1. 설명
deployment: GitHub가 관리하는 Deployment 객체가 생성되었을 때 트리거됨.
deployment_status: 배포 상태가 업데이트(예: 성공/실패)될 때 트리거됨.
2-2. 활용도
GitHub의 Deployment 기능과 연계하여 CI/CD 파이프라인을 정교하게 구성 가능.
배포 상태를 모니터링하고 후속 작업(예: 롤백, 알림)을 수행.
3. page_build
3-1. 설명
GitHub Pages를 빌드했을 때 트리거됨(GitHub Pages가 새로운 콘텐츠를 반영했을 때).
3-2. 활용도
Pages 업데이트 후후속 작업, 추가 알림, 사이트 모니터링 작업 수행.
워크플로우 자체 관련 이벤트
1. workflow_dispatch
수동 트리거임.
외부 API(REST API) 호출로도 트리거가 가능함.
CI/CD 파이프라인 외부에서 웹훅처럼 구동할 때도 유용함.
2. workflow_run
2-1. 설명
특정 워크플로우가 완료되었을 때(또는 특정 상태일 때) 다른 워크플로우를 실행함.
2-2. 사용 예시
on:
workflow_run:
workflows: ["Build and Test"]
types: [completed] # requested, completed
2-3. 활용도
하나의 워크플로우(예: 빌드 & 테스트)가 끝난 뒤, 후속 워크플로우(예: 배포)를 자동으로 수행하거나 파이프라인 단계적 수행함.
모노레포(monorepo) 형태에서 여러 워크플로우를 순차적으로 구성할 때 유용.
외부 트리거 및 기타 이벤트
1. repository_dispatch
1-1. 설명
외부 서비스에서 GitHub API를 호출해 특정 이벤트를 저장소로 ‘디스패치’할 수 있음.
REST API의 /repos/{owner}/{repo}/dispatches 엔드포인트를 통해 임의의 페이로드를 보내면 해당 이벤트가 트리거됨.
1-2. 사용 예시
on:
repository_dispatch:
types: [custom-event]
1-3. 활용도
외부 CI/CD 툴 또는 사내 시스템과 연동해서 “정말” 원하는 시점에 GitHub Actions을 구동함.
client_payload를 통해 다양한 데이터를 전달받을 수 있어, 유연한 자동화 시나리오 구성 가능.
2. schedule
2-1. 설명
cron 표현식을 사용하여 일정에 따라 워크플로우를 실행함. (UTC 기준)
2-2. 사용 예시
on:
schedule:
- cron: '0 3 * * *' # 매일 새벽 3시에 실행 (UTC 기준)
- cron: '0 */6 * * *' # 6시간 마다 실행
2-3. 활용도
정기 점검(예: SAST, DAST, 린트) 또는 배치(batch) 작업.
데이터 백업, 리포트 생성, 인프라 상태 점검 자동화.
3. watch, star, fork, public, member, gollum(wiki), discussion 등
3-1. 설명
저장소에 대한 watch/star/fork가 발생하거나, 위키 문서(gollum)가 업데이트되거나, discussion이 생성/수정되는 등의 다양한 GitHub 이벤트가 발생했을 때 트리거됨.
3-2. 활용도
스타가 달렸을 때 무엇인가를 기록하거나 축하 알림 등을 보낼 수 있음(주로 재미/마케팅 요소).
위키나 discussion 업데이트 알림, 문서 자동화 파이프라인.
주의 사항
1. 보안 이슈(시크릿 노출 위험)
포크된 PR에서 워크플로우가 실행될 때, 시크릿 값을 무분별하게 노출하지 않도록 구성해야 함.
pull_request_target 사용 시에는 조심스럽게 권한을 제한하거나, 필요한 경우에만 시크릿을 공개하는 방식을 사용함.
2. 이벤트 필터(branch, tag 등) 이해
on.push.branches와 on.pull_request.branches는 PR 발생 브랜치(head)인가, 아니면 머지될 브랜치(base)인가에 따라 다름.
문서를 꼼꼼히 확인하여 의도한 대로 필터링해야 함.
3. 이벤트 ‘types’ 지정 유무
on: pull_request만 쓰면 opened, closed, reopened, synchronize 등 모든 서브 이벤트에 대응함.
types를 사용해 세분화하면 워크플로우 실행 횟수를 줄이고, 불필요한 CI 낭비를 막을 수 있음.
4. 조건부 실행(using if)
GitHub Actions의 YAML에서 if: github.event_name == 'push' && ... 형태로 조건을 세분화해 실제 스텝이 실행되는 방식을 제어할 수 있음.
큰 저장소(또는 모노레포)일수록 이벤트는 다양하게 발생하므로, 파이프라인 효율을 높이려면 조건부 실행이 필수적임.
5. 병렬/순차 실행(workflow_run을 이용한 파이프라인화)
이벤트를 트리거하는 워크플로우 간의 종속성을 설정할 때 workflow_run 이벤트를 사용함.
이를 통해 한 워크플로우의 작업이 끝난 후 자동으로 다른 워크플로우를 실행하는 CI/CD 파이프라인을 구성할 수 있음.
6. CRON 시 주의 시간대(UTC)
schedule은 UTC 기준이므로, 한국 시간(KST, UTC+9)과 시차가 생김.
필요한 경우 이를 고려해 CRON 설정을 하거나, 워크플로우 내에서 시간대를 변환하여 사용해야 함.
7. Self-hosted Runner 권한 관리
기업 환경에서 셀프 호스티드 러너를 사용하는 경우, 각 이벤트가 어떤 권한으로 어떤 머신에서 실행되는지 모니터링해야 함.
보안을 위해 이벤트마다 토큰 권한(permissions)을 최소화하거나, 필요 시 특정 이벤트에 대해서만 셀프 호스티드 러너를 사용하도록 설정해야 함.
정리
GitHub Actions의 on 키워드는 GitHub 리포지토리에서 발생할 수 있는 거의 모든 이벤트, 그리고 CRON 스케줄, 수동/외부 트리거까지 폭넓은 시나리오를 지원함.
이벤트를 효율적으로 사용하면 자동화 파이프라인을 매우 유연하게 설계할 수 있지만, 동시에 보안과 리소스 사용에 대한 주의가 필요함.
각 이벤트의 특성과 컨텍스트를 깊이 이해하고, 프로젝트 혹은 조직의 요구사항에 맞게 필터링(branch, types)과 조건부 실행, 시크릿 관리 등을 적절히 조합하면, 강력하고 안전한 CI/CD 환경을 구축할 수 있음.
'Operating System > Computer' 카테고리의 다른 글
| [Computer] ChatOps (2) | 2025.03.01 |
|---|---|
| [Computer] Github Action (0) | 2025.02.22 |
| [Computer] 로드밸런서 (0) | 2025.01.29 |
| [Computer] 프로세스의 문맥 교환 (0) | 2025.01.28 |
| [Computer] 멀티프로세싱 및 멀티스레딩 (0) | 2025.01.27 |
Github Action의 on 이벤트 종류
GitHub Actions의 on 키워드는 워크플로우가 언제(trigger) 실행될지를 정의함.
이 필드는 매우 유연하며 다양한 이벤트에 반응하도록 설정할 수 있음.
이벤트는 크게 GitHub 이벤트(push, pull_request 등), 배포/릴리스 이벤트(release, deployment, page_build 등), 이슈 관련 이벤트(issues, issue_comment 등), 워크플로우 자체 이벤트(workflow_dispatch, workflow_run 등)로 분류할 수 있음.
또한 schedule을 사용하면 정해진 시간 간격(CRON)으로 워크플로우를 실행할 수도 있음.
저장소의 기본 이벤트 (Commit, PR 관련 등)
1. push
1-1. 설명
저장소에 푸시가 발생했을 때 실행됨(브랜치, 태그 포함).
일반적으로 가장 많이 사용하는 이벤트 중 하나임.
1-2. 사용 예시
on:
push:
branches:
- main
- 'feature/*'
tags:
- 'v*.*.*'
branches: 특정 브랜치에만 반응하도록 설정할 수 있음.
tags: 태그가 푸시될 때만 반응하도록 설정할 수 있음.
1-3. 주의사항
포크(fork)에서 생성된 푸시 이벤트는 기본적으로 워크플로우가 실행되지 않음.
보안 이슈를 방지하기 위함임.
푸시 이벤트 내 HEAD 커밋에서만 이벤트 컨텍스트를 가져올 수 있음.
2. pull_request
2-1. 설명
Pull Request(이하 PR)가 열렸을 때, 변경되었을 때(커밋이 추가되거나 타겟 브랜치가 바뀌거나), re-open될 때, 혹은 PR이 동기화될 때(triggered by synchronizing)가 있을 때 실행됨.
2-2. 사용 예시
on:
pull_request:
types: [opened, reopened, synchronize]
branches:
- main
- 'release/*'
types로 세분화할 수 있음.
예를 들어, opened, closed, reopened, synchronize, edited, assigned 등이 있음.
특정 브랜치로의 PR에만 반응하도록 설정할 수도 있음.
2-3. 주의사항
PR 이벤트가 발생할 때는 github.event.pull_request 컨텍스트 안에 상세 정보가 담겨 있으므로 이를 적극 활용해 QA, 빌드, 테스트 등의 작업을 진행할 수 있음.
외부 기여(Fork PR)에 대한 보안 정책을 주의해야 함(특히 GitHub Actions의 시크릿 사용).
3. pull_request_target
3-1. 설명
pull_request_target 이벤트는 ‘대상 브랜치의 워크플로우’를 기준으로 실행된다는 점에서 pull_request 이벤트와 차이가 있음.
즉, PR이 온 저장소의 기본 브랜치나 워크플로우 파일이 존재하는 브랜치의 워크플로우 구성이 적용됨.
3-2. 사용 예시
on:
pull_request_target:
types: [opened, reopened, synchronize]
3-3. 주의사항
pull_request_target은 포크에서 온 PR에 대해서도 시크릿을 사용할 수 있게 만듬.
하지만 이는 보안상 주의가 필요하며, 외부 커밋이 실행 권한을 얻을 수 있으므로 민감한 정보를 다루는 일에는 신중해야 함.
pull_request_target의 컨텍스트는 PR의 head SHA를 체크아웃하지 않고, base 브랜치의 코드를 체크아웃한다는 점이 중요함.
4. create, delete
4-1. 설명
create: 브랜치나 태그가 새로 생성되었을 때 실행됨.
delete: 브랜치나 태그가 삭제되었을 때 실행됨.
4-2. 사용 예시
on:
create:
branches:
- 'feature/*'
tags:
- 'v*.*.*'
delete:
branches: [ 'hotfix/*' ]
4-3. 활용도
브랜치 생성 시 자동 초기 세팅 작업 등(예: 이슈 템플릿 자동 생성)을 할 수 있음.
브랜치 삭제 시 청소(clean-up) 작업, 자동 리소스 정리, 태그 삭제 후 후속 작업 등을 할 수 있음.
5. workflow_dispatch
5-1. 설명
사용자(또는 API)에 의해 수동으로 워크플로우를 실행(trigger)할 수 있는 이벤트임.
GitHub Actions UI에서 ‘Run workflow’ 버튼을 통해 인풋을 지정해 실행하는 방식임.
5-2. 사용 예시
on:
workflow_dispatch:
inputs:
environment:
description: 'Which environment to deploy to?'
required: true
default: 'staging'
version:
description: 'Version to deploy'
required: false
5-3. 활용도
테스트 또는 배포 등 임의 시점에 실행해야 하는 작업을 위한 수동 트리거임.
여러 입력값(inputs)을 받아서 조건에 따라 다른 스크립트를 실행하는 식으로 설계할 수 있음.
이슈 및 기타 GitHub 관리 이벤트
1. issues
1-1. 설명
이슈가 생성, 수정, 할당(assigned), 라벨 변경, 열림, 닫힘, 재오픈 등 다양한 액션(types)을 기준으로 트리거됨.
1-2. 사용 예시
on:
issues:
types: [opened, edited, assigned, closed]
1-3. 활용도
새 이슈 생성 시 메시지 자동 댓글, 라벨 자동 할당(예: triage) 등의 작업.
이슈가 닫힐 때 기록 자동화, 통계 집계, 외부 API 호출 등.
2. issue_comment
2-1. 설명
이슈 혹은 PR의 코멘트가 달릴 때(또는 수정, 삭제될 때) 실행됨.
2-2. 사용 예시
on:
issue_comment:
types: [created, edited, deleted]
2-3. 활용도
특정 명령어 형식의 댓글을 트리거로 작업 실행(“/deploy” 같은 챗옵스).
코멘트 내용 분석 후 자동 메타 정보 업데이트 또는 CI 재실행 등.
3. label
3-1. 설명
라벨(Label)이 생성, 삭제, 수정될 때 트리거됨.
3-2. 사용 예시
on:
label:
types: [created, deleted, edited]
3-3. 활용도
레이블 사용 현황을 추적하거나, 특정 레이블이 추가되면 다른 이슈/PR을 자동 업데이트함.
4. milestone
4-1. 설명
마일스톤이 생성, 열림, 닫힘, 편집 등 되었을 때 트리거됨.
4-2. 사용 예시
on:
milestone:
types: [created, closed]
4-3. 활용도
마일스톤이 닫힐 때 이슈 및 PR 상태 자동 업데이트, 배포 태그와 연결되는 작업 수행함.
5. project, project_card, project_column
5-1. 설명
GitHub Projects(프로젝트 보드) 관련 이벤트로, 프로젝트가 생성/업데이트/삭제되거나 프로젝트 카드/컬럼이 생성, 이동, 삭제되는 등 다양한 이벤트를 트리거로 사용할 수 있음.
5-2. 활용도
작업 보드에서 카드가 특정 컬럼으로 이동하면 자동 알림, 자동 태그 부여 등의 워크플로우.
배포, 릴리스, 빌드 관련 이벤트
1. release
1-1. 설명
릴리스가 생성, 수정, 게시, 취소, 삭제될 때 트리거됨.
1-2. 사용 예시
on:
release:
types: [published, created, edited]
1-3. 활용도
새 버전 릴리스 시 자동 빌드 & 배포 파이프라인 실행함.
릴리스 노트를 슬랙 등에 자동 게시됨.
2. deployment, deployment_status
2-1. 설명
deployment: GitHub가 관리하는 Deployment 객체가 생성되었을 때 트리거됨.
deployment_status: 배포 상태가 업데이트(예: 성공/실패)될 때 트리거됨.
2-2. 활용도
GitHub의 Deployment 기능과 연계하여 CI/CD 파이프라인을 정교하게 구성 가능.
배포 상태를 모니터링하고 후속 작업(예: 롤백, 알림)을 수행.
3. page_build
3-1. 설명
GitHub Pages를 빌드했을 때 트리거됨(GitHub Pages가 새로운 콘텐츠를 반영했을 때).
3-2. 활용도
Pages 업데이트 후후속 작업, 추가 알림, 사이트 모니터링 작업 수행.
워크플로우 자체 관련 이벤트
1. workflow_dispatch
수동 트리거임.
외부 API(REST API) 호출로도 트리거가 가능함.
CI/CD 파이프라인 외부에서 웹훅처럼 구동할 때도 유용함.
2. workflow_run
2-1. 설명
특정 워크플로우가 완료되었을 때(또는 특정 상태일 때) 다른 워크플로우를 실행함.
2-2. 사용 예시
on:
workflow_run:
workflows: ["Build and Test"]
types: [completed] # requested, completed
2-3. 활용도
하나의 워크플로우(예: 빌드 & 테스트)가 끝난 뒤, 후속 워크플로우(예: 배포)를 자동으로 수행하거나 파이프라인 단계적 수행함.
모노레포(monorepo) 형태에서 여러 워크플로우를 순차적으로 구성할 때 유용.
외부 트리거 및 기타 이벤트
1. repository_dispatch
1-1. 설명
외부 서비스에서 GitHub API를 호출해 특정 이벤트를 저장소로 ‘디스패치’할 수 있음.
REST API의 /repos/{owner}/{repo}/dispatches 엔드포인트를 통해 임의의 페이로드를 보내면 해당 이벤트가 트리거됨.
1-2. 사용 예시
on:
repository_dispatch:
types: [custom-event]
1-3. 활용도
외부 CI/CD 툴 또는 사내 시스템과 연동해서 “정말” 원하는 시점에 GitHub Actions을 구동함.
client_payload를 통해 다양한 데이터를 전달받을 수 있어, 유연한 자동화 시나리오 구성 가능.
2. schedule
2-1. 설명
cron 표현식을 사용하여 일정에 따라 워크플로우를 실행함. (UTC 기준)
2-2. 사용 예시
on:
schedule:
- cron: '0 3 * * *' # 매일 새벽 3시에 실행 (UTC 기준)
- cron: '0 */6 * * *' # 6시간 마다 실행
2-3. 활용도
정기 점검(예: SAST, DAST, 린트) 또는 배치(batch) 작업.
데이터 백업, 리포트 생성, 인프라 상태 점검 자동화.
3. watch, star, fork, public, member, gollum(wiki), discussion 등
3-1. 설명
저장소에 대한 watch/star/fork가 발생하거나, 위키 문서(gollum)가 업데이트되거나, discussion이 생성/수정되는 등의 다양한 GitHub 이벤트가 발생했을 때 트리거됨.
3-2. 활용도
스타가 달렸을 때 무엇인가를 기록하거나 축하 알림 등을 보낼 수 있음(주로 재미/마케팅 요소).
위키나 discussion 업데이트 알림, 문서 자동화 파이프라인.
주의 사항
1. 보안 이슈(시크릿 노출 위험)
포크된 PR에서 워크플로우가 실행될 때, 시크릿 값을 무분별하게 노출하지 않도록 구성해야 함.
pull_request_target 사용 시에는 조심스럽게 권한을 제한하거나, 필요한 경우에만 시크릿을 공개하는 방식을 사용함.
2. 이벤트 필터(branch, tag 등) 이해
on.push.branches와 on.pull_request.branches는 PR 발생 브랜치(head)인가, 아니면 머지될 브랜치(base)인가에 따라 다름.
문서를 꼼꼼히 확인하여 의도한 대로 필터링해야 함.
3. 이벤트 ‘types’ 지정 유무
on: pull_request만 쓰면 opened, closed, reopened, synchronize 등 모든 서브 이벤트에 대응함.
types를 사용해 세분화하면 워크플로우 실행 횟수를 줄이고, 불필요한 CI 낭비를 막을 수 있음.
4. 조건부 실행(using if)
GitHub Actions의 YAML에서 if: github.event_name == 'push' && ... 형태로 조건을 세분화해 실제 스텝이 실행되는 방식을 제어할 수 있음.
큰 저장소(또는 모노레포)일수록 이벤트는 다양하게 발생하므로, 파이프라인 효율을 높이려면 조건부 실행이 필수적임.
5. 병렬/순차 실행(workflow_run을 이용한 파이프라인화)
이벤트를 트리거하는 워크플로우 간의 종속성을 설정할 때 workflow_run 이벤트를 사용함.
이를 통해 한 워크플로우의 작업이 끝난 후 자동으로 다른 워크플로우를 실행하는 CI/CD 파이프라인을 구성할 수 있음.
6. CRON 시 주의 시간대(UTC)
schedule은 UTC 기준이므로, 한국 시간(KST, UTC+9)과 시차가 생김.
필요한 경우 이를 고려해 CRON 설정을 하거나, 워크플로우 내에서 시간대를 변환하여 사용해야 함.
7. Self-hosted Runner 권한 관리
기업 환경에서 셀프 호스티드 러너를 사용하는 경우, 각 이벤트가 어떤 권한으로 어떤 머신에서 실행되는지 모니터링해야 함.
보안을 위해 이벤트마다 토큰 권한(permissions)을 최소화하거나, 필요 시 특정 이벤트에 대해서만 셀프 호스티드 러너를 사용하도록 설정해야 함.
정리
GitHub Actions의 on 키워드는 GitHub 리포지토리에서 발생할 수 있는 거의 모든 이벤트, 그리고 CRON 스케줄, 수동/외부 트리거까지 폭넓은 시나리오를 지원함.
이벤트를 효율적으로 사용하면 자동화 파이프라인을 매우 유연하게 설계할 수 있지만, 동시에 보안과 리소스 사용에 대한 주의가 필요함.
각 이벤트의 특성과 컨텍스트를 깊이 이해하고, 프로젝트 혹은 조직의 요구사항에 맞게 필터링(branch, types)과 조건부 실행, 시크릿 관리 등을 적절히 조합하면, 강력하고 안전한 CI/CD 환경을 구축할 수 있음.
'Operating System > Computer' 카테고리의 다른 글
| [Computer] ChatOps (2) | 2025.03.01 |
|---|---|
| [Computer] Github Action (0) | 2025.02.22 |
| [Computer] 로드밸런서 (0) | 2025.01.29 |
| [Computer] 프로세스의 문맥 교환 (0) | 2025.01.28 |
| [Computer] 멀티프로세싱 및 멀티스레딩 (0) | 2025.01.27 |
