GitHub Actions 워크플로우를 자극하는 주요 이벤트 정리
우리가 코드를 관리하는 GitHub의 저장소(repository)에서는 여러가지 일(event)들이 일어날 수 있죠? 개발자가 새로운 커밋(commit)을 푸시(push)할 수도 있고, 기여자(contributor)가 PR(pull request)을 제출하거나 사용자가 이슈(issue)를 보고할 수도 있습니다.
GitHub Actions를 사용하면 이렇게 GitHub 저장소에서 일어나는 다양한 이벤트에 자동으로 반응하도록 워크플로우(workflow)를 구성할 수 있는데요. 이번 포스팅에서는 GitHub Actions에서 워크플로우를 실행되게 만드는 다양한 방법과 현업 프로젝트에서 많이 사용되는 이벤트를 정리해보겠습니다.
on 키
워크플로우 YAML 파일의 on 키는 해당 워크플로우가 언제 실행되는지를 결정하는데요.
단순하게 하나의 이벤트에 반응하게 하려면 on 키에 이벤트 이름을 넘깁니다.
name: Our Triggers
on: push여러 개의 이벤트에 반응하게 하려면 on 키에 이벤트 이름을 배열의 형태로 넘깁니다.
name: Our Triggers
on: [push, pull_request]좀 더 세밀한 조정을 위해서는 on 키에 이벤트 이름과 추가 옵션을 객체의 형태로 넘길 수도 있습니다.
name: Our Triggers
on: push: branches: [main] pull_request: types: [opened, ready_for_review]push 이벤트
GitHub Actions에서 아마도 가장 많이 사용되는 이벤트는 push 이벤트일 텐데요.
push 이벤트는 새로운 커밋(commit)이 GitHub의 저장소로 유입되었을 때 발생합니다.
좀 더 쉽게 얘기해서 개발자가 git push 명령어를 사용하였을 때 일어납니다.
name: Our Push
on: push: branches: - main - "releases/**"여러 개발자가 협업하는 프로젝트에서는 위와 같이 main이나 master와 같은 기본 브랜치에서 발생하는 push 이벤트만 처리하도록 워크플로우를 구성하는 경우가 많은데요.
GitHub 저장소 내의 모든 브랜치를 상대로 push 이벤트를 처리하면 워크플로우가 너무 빈번하게 실행될 것이기 때문입니다.
보통 개발자들이 사용하는 기능(feature) 브랜치를 상대로는 다음에 다룰 pull_request 이벤트를 통해서 처리하는 경우가 많습니다.
만약에 특정 경로에서만 발생한 push 이벤트만 처리하고 싶다면 paths 키를 통해서 해당 경로를 명시해줄 수 있습니다.
예를 들어, 자바스크립트나 타입스크립트 파일이 변경되었을 때만 워크플로우가 반응하도록 설정해볼까요?
name: Our Push
on: push: paths: - "**/*.[jt]s?(x)"반대로 특정 경로에서 일어난 push 이벤트를 무시하고 싶다면 paths-ignore 키에 해당 경로를 지정해줄 수 있습니다.
예를 들어서, docs 디렉토리에 있는 문서 파일들을 변경되었을 때는 워크플로우가 실행되지 않도록 설정해보겠습니다.
name: Our Push
on: push: paths-ignore: - "docs/**"push 이벤트는 일반 커밋 뿐만 아니라 태그(tag)가 GitHub의 저장소로 유입되었을 때도 발생합니다.
예를 들어, 태그 중에서도 이름이 v로 시작하는 태그가 코드 저장소로 유입되었을 때만 반응하도록 워크플로우를 설정할 수 있습니다.
name: Our Push
on: push: tags: - v*pull_request 이벤트
pull_request 이벤트를 사용하면 개발자들이 제출하는 PR(pull request)에 자동으로 반응하는 워크플로우를 구성할 수 있습니다.
주로 코드 컴파일(compile), 포맷(format), 린트(lint), 테스트(test)와 같은 코드 품질 검사를 수행하는 CI 파이프라인(pipeline)을 만들 때 많이 사용됩니다.
PR 단계에서 품질 기준에 미치치 못하는 코드가 기본 브랜치로 머지(merge)되는 것을 방지하기 위함이죠.
name: Our PR
on: pull_requestjobs:
format:
# ...
lint:
# ...
test:
# ...PR에는 여러가지 세부 활동(activity)들을 발생할 수 있기 때문에 types 키를 통해서 반응 범위를 특정 활동으로 제한할 수 있는데요.
types 키를 명시하지 않으면 기본적으로 opened, synchronize, reopened 활동에만 워크플로우가 반응하게 됩니다.
synchronize 활동은 PR 브랜치에 새로운 커밋(commit)이 추가되었거나 최상위(head) 커밋이 변경되었음을 의미합니다.
types 키의 대표적인 활용 사례로 PR이 닫혔을 때 GitHub 저장소에서 관련 브랜츠를 삭제하는 등의 정리 작업을 자동화하고 싶을 때를 들 수 있는데요.
이 때는 types 키에 closed 활동을 명시하여 PR이 기본 브랜치로 머지되었거나 제출자가 닫았을 때만 해당 워크플로우가 실행되게 할 수 있습니다.
name: Our PR
on: pull_request: types: [closed]issues 이벤트
issues 이벤트를 사용하면 GitHub 저장소에 보고되는 이슈(issue)에 자동으로 반응하는 워크플로우를 구성할 수 있는데요.
기본적으로 하나의 이슈에서 일어나는 모든 활동에 대해서 반응이 일어나게 되며 types 키로 활동을 제한해줄 수 있습니다.
예를 들어, 누군가가 GitHub 저장소에 이슈를 제출할 시에만 실행하고 싶은 워크플로우에는 types 키를 opened로 지정해주면 됩니다.
이슈에 자동으로 태그를 붙여주는 등의 자동화를 할 때 유용하겠죠?
name: Our Issues
on: issues: types: [opened]issue_comment 이벤트
issue_comment 이벤트를 통해서 GitHub 저장소에서 이슈나 PR에 댓글을 달렸을 때 자동으로 반응하는 워크플로우를 구성할 수 있는데요.
기본적으로 댓글이 생성(created), 삭제(deleted), 수정(edited)되었을 때 반응이 일어나게 되며 types 키로 활동을 제한해줄 수 있습니다.
예를 들어, 누군가가 댓글을 달거나 수정할 시에만 실행하고 싶은 워크플로우에는 types 키를 created와 edited 지정해주면 됩니다.
보통 PR에 변경이 발생할 때 마다 매번 실행하기 시간이나 비용적으로 부담스럽거나 작업을 선택적으로 특정 댓글을 달았을 때만 실행되도록 하고 싶을 때 활용하면 좋습니다.
name: Our IC
on: issue_comment: types: [created, edited]release 이벤트
GitHub 저장소에서 릴리즈(release)가 생성되었을 때 반응하는 워크플로우를 구성하려면 release 이벤트를 사용합니다.
기본적으로 하나의 릴리즈에서 일어나는 모든 활동에 대해서 반응이 일어나게 되며 types 키로 활동을 제한해줄 수 있습니다.
예를 들어, 릴리즈가 발행되었을 때만 실행하고 싶은 워크플로우에는 types 키를 published로 지정해주면 됩니다.
name: Our Release
on: release: types: [published]schedule 이벤트
GitHub Actions를 리눅스의 크론탭(crontab)처럼 일정 주기에 맞춰서 반복적으로 실행할 수 있다는 사실을 아시나요?
on 키를 이벤트 대신에 schedule로 설정해주고 그 하위에 cron 키로 반복 주기를 명시해주면 되는데요.
크론탭의 분 시 날 월 요일 문법을 따르면 되고 반드시 UTC 시간대로 명시를 해야하며 최소 5분 간격으로 워크플로우를 실행할 수 있습니다.
예를 들어, 월요일부터 금요일까지 새벽 2시에 어떤 워크플로우를 실행하고 싶다면 다음과 같이 설정해주면 됩니다.
name: Our Schedule
on: schedule: - cron: "0 2 * * 1-5" # 분 시 날 월 요일workflow_dispatch 이벤트
만약에 워크플로우를 수동으로 실행하고 싶다면 어떻게 해야 할까요?
이때는 on 키를 workflow_dispatch로 설정하면 되는데요.
이렇게 해주면 GitHub 저장소의 Actions 탭에서 해당 워크플로우를 수동으로 실행할 수 있는 버튼이 활성화됩니다.
name: Our Manual
on: workflow_dispatch:이 기능은 테스트하거나 디버깅할 때 상당히 유용하며 특정 이벤트에 자동으로 반응하는 워크플로우에도 비상 시 수동 실행을 위해서 설정해놓는 경우도 있습니다.
workflow_call 이벤트
하나의 워크플로우 내에서 또 다른 워크플로우를 호출할 수 있다는 사실을 알고 계신가요? 보통 이렇게 다른 워크플로우가 호출하는 워크플로우를 재사용 가능한(reusable) 워크플로우라고 하는데요.
어떤 워크플로우가 재사용 가능한 워크플로우를 호출하면 workflow_call 이벤트가 발생합니다.
따라서 재사용 가능한 워크플로우가 이 이벤트 반응할 수 있도록 설정해줘야 합니다.
name: Our Triggers
on: workflow_call:재사용 가능한 워크플로우를 사용하는 방법에 대해서는 별도 포스팅에서 자세히 다루고 있습니다.
실습 코드
본 포스팅에서 작성한 YAML 파일과 워크플로우 실행 결과는 아래 코드 저장소에서 확인하실 수 있습니다.
https://github.com/DaleSchool/github-actions-triggers
마치면서
지금까지 GitHub Actions에서 워크플로우를 실행할 수 있는 다양한 방법에 대해서 알아보았습니다. GitHub 저장소에서 일어나는 다양한 이벤트에 자동으로 반응하게 할 수도 있고, 특정 스케줄에 의해서 주기적으로 실행되게 할 수도 있으며, 워크플로우를 수동으로 실행할 수 있는 옵션이 있다는 것을 배웠습니다. 너무 많아서 본 포스팅에서는 미처 다루지 못한 이벤트에 대해서는 GitHub Actions 공식 문서를 참고 바랍니다.
GitHub Actions 관련 포스팅은 GitHub Actions 태그를 통해서 쉽게 만나보세요!
This work is licensed under CC BY 4.0
