Github Actions - Filter

Filter

필터란 언제 무엇을 실행할지 걸러낼지를 지정하는 규칙을 의미한다.

크게 두가지로 나뉘는데 

• 이벤트 트리거 필터(workflow 수준) : 워크 플로우 자체를 아예 시작할지말지를 결정한다
• 조건식 필터(Job / Step 수준) : 워크 플로우가 시작된 후 각 job/step을 실행할지 말지를 결정한다

이벤트 트리거 필터

이벤트 트리거 필터는 워크 플로우가 돌지를 결정하는 것으로 on 아래에 설정하며, 대표적으로 branches / tags / paths가 있다.

on:
  push:
    branches: [ main, 'release/*' ]   # 이 브랜치에 푸시될 때만
    tags:     [ 'v*' ]                # v로 시작하는 태그 푸시일 때만
    paths:    [ 'app/**', '!app/docs/**' ]  # 변경 파일이 app/에 있을 때만

 

 

이벤트 트리거 필터: Branch Filter

브랜치 필터는 어떤 브랜치의 이벤트에만 워크플로우가 트리거 혹은 제외할지를 결정하는 규칙으로 on: 아래의 branches / branches-ignore 옵션을 설정해서 사용하며 주로 push와 pull_request 이벤트에서 사용한다.

• push 이벤트에서의 branch filter : 푸시된 브랜치 이름이 필터와 매칭될 때만 워크플로우가 실행된다
• pull_request 이벤트에서의 branch filter : 대상(base)브랜치(pr을 요청받는 Branch)가 필터와 매칭될 때만 시작됨 

 

한번 만들어서 테스트 해보면서 알아보자.

먼저 파일을 하나 생성해주고

name을 지정해주고

on의 아래에 push 이벤트를 등록하고 하위에 branches를 넣어주고 그 값으로 배열의 형태로 브랜치명을 넣어주면 된다.

그 외에 job과 step같은 경우는 편한대로 넣어주자.

이제 commit & push 해주고

Github로 가보면

dev 브랜치에서는 정상적으로 workflow가 돌아간것을 확인할 수 있다.

 

이제 다른 브랜치에서도 push 해보자

다른 브랜치 switch 하고

dev브랜치와 merge해준 다음에 

conflict난 파일을 확인 한 후에

수정해주고

다시 commit & push 해주고

README.md파일을 조금 수정해주고

commit & push 해주면

workflow가 실행되지 않는 것을 볼 수 있다.

 

pull_request의 경우는 이 기준이 pull request를 요청하는 브랜치가 무엇인지를 기준으로 workflow가 실행되는지 안되는지를 지정한다는 점만 다르고 동작은 동일하다.

 

이벤트 트리거 필터: Path Filter

path filter는 커밋에서 어떤 파일 경로가 바뀌었는지를 기준으로 워크플로우를 트리거할지 말지를 지정하는 명령어이다.

위치는 동일하게 on이하에 paths라는 하위에 작성하며 path는 포함하는 기준이 되고 path-ignore는 제외하는 기준이 된다.

동작은 지정한 위치의 파일들이 바뀐 경우에 해당하며 이때 보통 **(와일드카드)를 사용한다.

Path Filter는 push, pull_request, pull_reqeust_target 등의 이벤트에서 지원하고 workflow_dispatch, schedule에서는 지원하지 않는다.(이런 경우는 잡/스텝의 if:로 자체 분기해야 함)

 

한번 만들어서 테스트 해보면서 알아보자.

먼저 폴더를 두개 생성해주고

하위에 txt파일을 하나 씩 만들어서 내용을 아무렇게 나 채워주자.

이제 workflow를 생성해보자.

파일을 하나 만들어주고

name을 지정해주고

on아래에 push 이벤트를 걸고 그 하위에 paths를 넣은 후에 -(언더바)와 함께 변경을 인지할 dev_test에만 **로 dev_test 하위항목들의 변화에만 workflow가 돌아갈 수 있도록 설정해주자.

이제 job과 step부분은 그냥 편한대로 만들어주자.

이제 commit & push 해주고

 

이제 dev_origin의 내부에 파일을 수정해주고

commit & push 해주면

workflow에 내가 올린 커밋 메세지를 기반으로 workflow를 작동시키지 않는 것을 볼 수 있다.

 

이번에는 우리가 workflow에 작성했던 path인 dev_test의 내부의 파일을 변경해보자.

commit & push 해주고

github로 가보면

workflow가 실행된것을 볼 수 있다.

 

이벤트 트리거 필터: Tag Filter

tag filter는 on: 아래에 태그 푸시(생성, 업데이트)일 때 만 워크 플로우를 트리거하도록 하는 규칙이다.

주로 push 이벤트에서 tags / tags-ignore를 사용한다.

 

Git의 Tag에 대해서는 아래 접은 글 내부에서 확인하도록 하자.

Git의 Tag란

git에서의 tag란 다수의 커밋들중 특정 커밋에 지정하는 책갈피 라고 생각하면 된다.

이렇게 지정하는 tag는 커밋의 포인터가 앞으로 나가더라도 지정한 커밋에 고정된채 변하지 않는다.

 

보통 이런 tag는 개발하는 프로그램의 중요하다고 시작되는 시점(릴리즈 버전을 지정한다는가)에 사용된다.

보통 버전을 지정하는 시점에서 태그를 지정해서 영구적으로 해당 시점이 해당 버전임을 명시한다.

 

이 tag는 개발 과정 중 발생하는 많은 커밋들 중 이 시점의 커밋은 공식적으로 의미가 있는 시점이다 라고 명확하게 구분하주는 중요한 정보이기 때문에 신중하게 지정하여 설정해야한다.

 

tag는 아래 명령어를 통해서 추가할 수 있으며

# 메타 정보를 포함하는 경우
git tag -a v1.0.0 -m "버전 1.0.0 버전 릴리즈"


# 메타 정보들이 필요하지 않다면
git tag v1.0.0

 

-a : Annotated Tag로 태그를 별도의 객체로 만들어 Git 데이터베이스에 저장한다.
    -a를 달경우 메세지, 작성자 이름 및 메일, 태그 생성 시간을 포함하며 -m을 사용하기 위해선
    -a를 사용해야한다.
    작성자 이름 및 메일은 로컬 git 설정파일(.gitconfig)에 등록된 user.name과 user.email 값을

    (C:\Users\Administrator(User명)\.gitconfig에 위치함)

    사용해서 자동으로 생성하며 태그 생성 시간은 로컬 시스템의 현재 시간을 기록한다.

 

-m : 태그에 달 메세지

 

태그는 현재 브랜치와 독립적이며, 태그 명령을 실행할 당시 HEAD가 가리키는 커밋에 붙는다

(커밋 해시를 지정하면 어떤 과거 커밋에도 붙일 수도 있다.)

git의 origin에 태그를 push 하는 방법은

git push origin --tags

or 

git push origin v1.0.0(태그명)

으로 push할 수 있다

 

만약 commit과 같이 push를 하고자 한다면

git push origin branch_name --tags

or 

git push origin branch_name v1.0.0

으로 push가 가능하다

 

tag가 commit 시점 이후라면 tag는 commit에 붙고 commit 이전에 tag를 생성해서 붙였다면 현재 commit 이전 commit에 붙어 있게 된다.

 

또한 tag는 commit과 별개의 동작으로 commit과 tag를 단 후에 

git push origin branch_name

을 통해서 commit을 push 하고나서 

추가로 새로운 commit을 여러개 단 후에 

git push origin --tags

태그를 push하더라도 실제 tag를 달았던 commit에 tag가 달리게 된다.

Tag Filter의 경우는 tag가 로컬에서 생성되는 시점이 아니라 Github로 push 되는 시점에 발생하기에 먼저 workflow를 만들어주자.

파일을 하나 생성해주고

name을 지정해주고

push 이벤트의 하위에 tags의 값으로 배열로 만들어 주는데 

이때 태그 이름의 패턴을 매칭시킬 것이다.

우리가 태그를 v1.0.0과 같이 달 것이고 이런 버전에 대한 내용의 태그가 달릴 경우 workflow를 실행하고자 한다면

이런식으로 지정해주면 된다.

그러면 v1.0.0과 같은 형태로 오는 태그에 대해서는 workflow가 반응 하게 된다.

 

이제 job과 step은 임의로 간단하게 만들어주고

이를 우선 commit & push 해주고

 

이제 로컬에서 태그를 하나 생성해주고 

git에 해당 내용을 적용해주자.

그러면 Github에 

이렇게 workflow가 실행되는 것을 볼 수 있다.

 

조건식 필터

워크 플로우가 트리거된 후 각 job이나 step에서 if: 를 붙여서 실행 여부를 결정한다.

이때 표현식(${{}}) 내부에 Context(github.*, runner.*, inputs.* 등..)를 이용한다.

jobs:
  build:
    if: ${{ github.ref == 'refs/heads/main' && github.event_name == 'push' }}
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run only when label exists on PR
        if: ${{ contains(join(github.event.pull_request.labels.*.name, ','), 'run-ci') }}
        run: npm test