[CI/CD] Workflow Event

name: Project
on: [push, workflow_dispatch]

위 코드와 같이 기본적으로 워크플로 트리거 역할을 하는 대표적인 Event들이 있다.

 

Trigger Event	작동 설명
push	깃허브에 push했을시 workflow작동
pull_request	깃허브에서 pr했을시 workflow작동
create	분기나 태그를 만들었을 경우 workflow작동
fork	깃허브에서 누군가가 내 레포지토리를 fork했을 경우 workflow작동
issues	깃허브 issue관련된 일이 발생했을시 workflow작동
issue_comment	깃허브 issue 또는 pr에서 comment가 작성되었을 경우 workflow작동
watch	깃허브 저장소에 별표가 달렸을경우 workflow작동
discussion	깃허브 discussion 활동이 생길경우 workflow작동

 

Event의 종류는 이 것 말고도 더 많이 있다.

더 많은 Event들은 GitHub Docs에서 확인 할수 있다.

 

Activity Types(활동유형)

위 GitHub Docs에서 들어가서 확인해보면 간단하게 push와 pull_request를 비교해봤을때

push에는 없는데 pull_request에는 어떠한 활동들이 많은걸 볼수가 있다.

즉, 활동 유형은 내가 어떠한 행동을 했을때 발생한다고 보면된다.

push같은 경우에는 행동을 지정할수 있는 부분이 없다.

어떻게 보면 단순히 git add, commit, push하는 부분에서 크게 벗어나는게 없기 때문에 그런것이 아닐까 싶다. 

 

하지만 pull_request같은 경우에는 pull_request를 열었을 때, pull_request를 수정 했을 때, pull_request를 닫았을 때와 같이 여러한 행동들을 설정을 할수가 있다.

설정 형식은 아래와 같다.

on:
  pull_request:
    types: [opened, reopened]

 

맨 위에서 트리거를 설정할때는

on: [push, workflow_dispatch]

이렇게 했는데 형태가 달라졌다.

그 이유는 트리거 이벤트안에서의 설정이 또 생기게 됐으므로 별개로 설정을 해주어야 하기 때문에 tab으로 들여쓰기를 하여 구분해 준것이다.

그러면 여기서 어떻게 병렬 처리를 해주느냐? 이다.

간단하다.

on:
  pull_request:
    types: [opened, reopened]
  push:
  workflow_dispatch:

이렇게 하나씩 펼쳐주면된다.

만약 이벤트들의 해당 activity type에 설정이 필요하다면 해당 이벤트아래에 들여쓰기를 해주어 types에 설정해주면 된다.

 

 

Filters

activity type은 이벤트에서 어떠한 행동을 했을때 workflow가 작동되는 것이라면

Filters는 어떤 특정 파일또는 경로에서 해당 이벤트와 activity type이 발생했을때 workflow가 작동하도록 설정해주는 것이다.

 

branches

on:
  pull_request:
    types:
      - opened
    branches:
      - 'releases/**'

위 설정은 pr이 발생했을 때 그것의 활동이 opened일때 workflow가 발생합니다. 단, releases/**라는 브랜치 일때만 발생합니다.

이말은 브랜치를 설정했을때 releases/a, releases/b와 같은 브랜치가 pr이 열렸을 때 작동하도록 할수 가 있습니다.

마찬가지로

on:
  pull_request:
    types:
      - opened
    branches:
      - main # 메인 브랜치를의미
      - 'feat-**' # feat-login, feat-logout 과 같은 브랜치를 의미

위와 같이 이러한 브랜치에서만 pr이 발생했을 때로 설정을 할 수도 있다.

만약 위와 같은 설정을 한뒤 dev/comment라는 경로를 pr한다면 workflow는 작동을 하지 않게 됩니다.

 

path

특정 확장자파일이라면 작동할수있도록 필터링을 설정할수도 있다.

on:
  pull_request:
    paths:
      - '**.js'

.js라는 확장자의 경로가 pull_request된다면 workflow작동하도록 설정을 한다.

 

 

on:
  push:
    paths-ignore:
      - 'docs/**'

이 것은 docs폴더 아래의 파일들이 push된다면 workflow를 작동시키지 않겠다고 설정한것이다.

브랜치도 위와 같이 설정하며 무시하도록 설정을 할수가 있다.

 

더 많은 정보들은 GitHub Docs / GitHub Action / workflow syntax에서 확인할수가 있다.

 

 

workflow Skip

코드 로직을 재정비하고 push했을 때 workflow의 경로에 있지만 workflow를 실행시키지 않을수도 있다.

바로 그냥 넘기는 것이다. 광고를 다 보지 않고 넘기는 것처럼 skip하는 것이다.

git add .
git commit -m "fix: login jwt [skip ci]"

위처럼 커밋 메세지에 [skip ci], [no ci], [ci skip]과 같은 문구를 넣으면 해당 커밋은 workflow실행을 건너뛸수가 있다.

더 많은 skip에 대한 정보는 github action / workflow skip에서 확인할수 있다.