워크플로 트리거

참고: GitHub 호스트 실행기는 현재 GitHub Enterprise Server에서 지원되지 않습니다. GitHub public roadmap에 예정된 향후 지원에 대해 자세히 알아볼 수 있습니다.

워크플로 트리거 정보

워크플로 트리거는 워크플로를 실행하게 하는 이벤트입니다. 해당 이벤트는 다음과 같습니다.

워크플로의 리포지토리에서 발생하는 이벤트
GitHub Enterprise Server 외부에서 발생하고 GitHub Enterprise Server에서 repository_dispatch 이벤트를 트리거하는 이벤트
예약된 시간
설명서

예를 들어 리포지토리의 기본 분기로 푸시되거나, 릴리스가 생성되거나, 이슈가 열리면 실행되도록 워크플로를 구성할 수 있습니다.

워크플로 트리거는 on 키로 정의됩니다. 자세한 내용은 "GitHub Actions에 대한 워크플로 구문"을 참조하세요.

워크플로 실행을 트리거하려면 다음 단계를 수행합니다.

리포지토리에서 이벤트가 발생합니다. 이벤트에 연결된 커밋 SHA 및 Git 참조가 있습니다.
GitHub Enterprise Server는 리포지토리의 .github/workflows디렉터리에서 이벤트의 연결된 커밋 SHA 또는 Git 참조에 있는 워크플로 파일을 검색합니다.
on: 값이 트리거 이벤트와 일치하는 모든 워크플로에 대해 워크플로 실행이 트리거됩니다. 또한 일부 이벤트를 실행하려면 워크플로 파일이 리포지토리의 기본 분기에 있어야 합니다.

각 워크플로 실행은 이벤트의 연결된 커밋 SHA 또는 Git 참조에 있는 워크플로의 버전을 사용합니다. 워크플로가 실행되면 GitHub Enterprise Server는 실행기 환경에서 GITHUB_SHA(커밋 SHA) 및 GITHUB_REF(Git 참조) 환경 변수를 설정합니다. 자세한 내용은 "변수"을 참조하세요.

워크플로에서 워크플로 트리거

리포지토리의 GITHUB_TOKEN을 사용하여 작업을 수행하는 경우 GITHUB_TOKEN는 새 워크플로 실행을 만들지 않습니다. 이렇게 하면 실수로 재귀 워크플로 실행을 만들지 못하도록 방지됩니다. 예를 들어, 워크플로 실행이 리포지토리의 GITHUB_TOKEN을 사용하여 코드를 푸시하는 경우 리포지토리가 push 이벤트 발생 시 실행되도록 구성된 워크플로를 포함하고 있더라도 새 워크플로가 실행되지 않습니다. 자세한 내용은 "자동 토큰 인증.

워크플로 실행 내에서 워크플로를 트리거하려는 경우 GitHub App 설치 액세스 토큰 또는 토큰이 필요한 이벤트를 트리거하는 대신 GITHUB_TOKEN personal access token를 사용할 수 있습니다.

GitHub App을(를) 사용하는 경우 GitHub App을(를) 만들고 앱 ID와 프라이빗 키를 비밀로 저장해야 합니다. 자세한 내용은 "Making authenticated API requests with a GitHub App in a GitHub Actions workflow"을 참조하세요. personal access token을(를) 사용하는 경우 personal access token을(를) 만들어 비밀로 저장해야 합니다. personal access token을(를) 만드는 방법에 대한 자세한 내용은 "Managing your personal access tokens. 비밀 저장에 대한 자세한 내용은 "암호화된 비밀"을 참조하세요.

GitHub Actions 사용 비용을 최소화하려면 재귀 또는 의도하지 않은 워크플로 실행을 만들지 않도록 합니다.

예를 들어 다음 워크플로는 personal access token(라는 MY_TOKEN비밀로 저장됨)를 사용하여 GitHub CLI를 통해 문제에 레이블을 추가합니다. 레이블이 추가되면 실행되는 모든 워크플로는 이 단계가 수행되면 실행됩니다.

on:
  issues:
    types:
      - opened

jobs:
  label_issue:
    runs-on: ubuntu-latest
    steps:
      - env:
          GITHUB_TOKEN: ${{ secrets.MY_TOKEN }}
          ISSUE_URL: ${{ github.event.issue.html_url }}
        run: |
          gh issue edit $ISSUE_URL --add-label "triage"

반대로 다음 워크플로는 GITHUB_TOKEN을 사용하여 이슈에 레이블을 추가합니다. 레이블이 추가될 때 실행되는 워크플로는 트리거되지 않습니다.

on:
  issues:
    types:
      - opened

jobs:
  label_issue:
    runs-on: ubuntu-latest
    steps:
      - env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          ISSUE_URL: ${{ github.event.issue.html_url }}
        run: |
          gh issue edit $ISSUE_URL --add-label "triage"

이벤트를 사용하여 워크플로 트리거

on 키를 사용하여 워크플로를 트리거하는 이벤트를 지정합니다. 사용할 수 있는 이벤트에 대한 자세한 내용은 "워크플로를 트리거하는 이벤트"을 참조하세요.

단일 이벤트 사용

예를 들어 다음 on 값이 있는 워크플로는 워크플로 리포지토리의 분기로 푸시될 때 실행됩니다.

on: push

여러 이벤트 사용

단일 이벤트 또는 여러 이벤트를 지정할 수 있습니다. 예를 들어 다음 on 값이 있는 워크플로는 워크플로 리포지토리의 분기로 푸시될 때 실행됩니다.

on: [push, fork]

여러 이벤트를 지정하는 경우 워크플로를 트리거하려면 이러한 이벤트 중 하나만 발생해야 합니다. 워크플로에 대한 트리거 이벤트가 여러 개 동시에 발생하는 경우 워크플로 실행 여러 개가 트리거됩니다.

여러 이벤트와 함께 활동 유형 및 필터 사용

작업 유형 및 필터를 사용하여 워크플로가 실행되는 시기를 추가로 제어할 수 있습니다. 자세한 내용은 이벤트 작업 유형 사용 및 필터 사용을 참조하세요. 이벤트에 대해 작업 유형 또는 필터를 지정하고 여러 이벤트에서 워크플로가 트리거되는 경우 각 이벤트를 별도로 구성해야 합니다. 구성이 없는 이벤트를 포함하여 모든 이벤트에 콜론(:)을 추가해야 합니다.

예를 들어 다음 on 값이 있는 워크플로는 다음과 같은 경우에 실행됩니다.

레이블이 생성되는 경우
리포지토리의 main 분기에 푸시되는 경우
GitHub Pages 사용 분기에 푸시되는 경우

on:
  label:
    types:
      - created
  push:
    branches:
      - main
  page_build:

이벤트 작업 유형 사용

일부 이벤트에는 워크플로가 실행되어야 하는 시기를 보다 정확하게 제어할 수 있는 활동 유형이 있습니다. on.<event_name>.types를 사용하여 워크플로 실행을 트리거할 이벤트 활동 유형을 정의합니다.

예를 들어 issue_comment 이벤트에는 created, edited 및 deleted 활동 유형이 있습니다. label 이벤트에 대해 워크플로가 트리거되면 레이블을 만들거나 편집하거나 삭제할 때마다 이 워크플로가 실행됩니다. label 이벤트에 대해 created 활동 유형을 지정하면 레이블을 편집하거나 삭제할 때가 아니라 레이블을 만들 때 워크플로가 실행됩니다.

on:
  label:
    types:
      - created

활동 유형을 여러 개 지정한 경우 워크플로를 트리거하려면 이러한 이벤트 활동 유형 중 하나만 발생해야 합니다. 워크플로에 대한 트리거 이벤트 활동 유형 여러 개가 동시에 발생하는 경우 워크플로 실행 여러 개가 트리거됩니다. 예를 들어 다음 워크플로는 이슈가 시작되거나 레이블이 지정될 때 트리거됩니다. 레이블 두 개가 지정된 이슈가 시작되면 워크플로 실행 세 개가 시작됩니다. 하나는 이슈 시작됨 이벤트를 위한 실행이고, 두 개는 이슈에 레이블이 지정됨 이벤트 두 개를 위한 실행입니다.

on:
  issues:
    types:
      - opened
      - labeled

각 이벤트 및 해당 활동 유형에 대한 자세한 내용은 "워크플로를 트리거하는 이벤트"을 참조하세요.

필터 사용

일부 이벤트에는 워크플로가 실행되어야 하는 시기를 더 자세히 제어할 수 있는 필터가 있습니다.

예를 들어 push 이벤트에는 푸시가 발생하는 경우 대신 branches 필터와 일치하는 분기로 푸시가 발생하는 경우에만 워크플로가 실행되도록 하는 branches 필터가 있습니다.

on:
  push:
    branches:
      - main
      - 'releases/**'

필터를 사용하여 끌어오기 요청 이벤트에 특정 분기를 대상으로 지정

pull_request 및 pull_request_target 이벤트를 사용하는 경우 특정 분기를 대상으로 하는 끌어오기 요청에 대해서만 실행되도록 워크플로를 구성할 수 있습니다.

분기 이름 패턴을 포함하려는 경우 또는 분기 이름 패턴을 포함하거나 제외하려는 경우 branches 필터를 사용합니다. 분기 이름 패턴만 제외하려는 경우 branches-ignore 필터를 사용합니다. 워크플로의 동일한 이벤트에 대해 branches 필터와 branches-ignore 필터 둘 다는 사용할 수 없습니다.

및 를 paths/paths-ignore모두 branches/branches-ignore 정의하는 경우 두 필터가 모두 충족될 때만 워크플로가 실행됩니다.

branches 및 branches-ignore 키워드는 *, **, +, ?, ! 및 두 개 이상의 분기 이름을 찾기 위한 기타 문자 등의 문자를 사용하는 GLOB 패턴을 허용합니다. 이름에 해당 문자가 포함되어 있고 리터럴 일치를 원하는 경우 각 특수 문자를 \로 이스케이프해야 합니다. glob 패턴에 대한 자세한 내용은 "GitHub Actions에 대한 워크플로 구문"을 참조하세요.

예: 분기 포함

branches에 정의된 패턴은 Git ref의 이름에 따라 평가됩니다. 예를 들어 끌어오기 요청 대상 지정을 위한 pull_request 이벤트가 있을 때마다 다음 워크플로가 실행됩니다.

main으로 명명된 분기(refs/heads/main)
mona/octocat으로 명명된 분기(refs/heads/mona/octocat)
releases/10과 같이 이름이 releases/로 시작하는 분기(refs/heads/releases/10)

on:
  pull_request:
    # Sequence of patterns matched against refs/heads
    branches:    
      - main
      - 'mona/octocat'
      - 'releases/**'

예: 분기 제외

패턴이 branches-ignore 패턴과 일치하면 워크플로가 실행되지 않습니다. branches에 정의된 패턴은 Git ref의 이름에 따라 평가됩니다. 예를 들어 끌어오기 요청의 대상을 지정하지 않는 한 pull_request 이벤트가 있을 때마다 다음 워크플로가 실행됩니다.

mona/octocat으로 명명된 분기(refs/heads/mona/octocat)
releases/beta/3-alpha와 같이 이름이 releases/**-alpha와 일치하는 분기(refs/heads/releases/beta/3-alpha)

on:
  pull_request:
    # Sequence of patterns matched against refs/heads
    branches-ignore:    
      - 'mona/octocat'
      - 'releases/**-alpha'

예: 분기 포함 및 제외

branches 및 branches-ignore를 사용하여 단일 워크플로의 동일한 이벤트를 필터링할 수 없습니다. 단일 이벤트에 대한 분기 패턴을 포함 및 제외하려면 ! 문자와 함께 branches 필터를 사용하여 제외해야 하는 분기를 나타냅니다.

! 문자를 사용하여 분기를 정의하는 경우 ! 문자 없이 하나 이상의 분기도 정의해야 합니다. 분기만 제외하려면 branches-ignore를 대신 사용합니다.

패턴을 정의하는 순서가 중요합니다.

긍정 일치 후 일치하는 부정 패턴(접두사 !)은 Git ref를 제외합니다.
부정 일치 후 일치하는 긍정 패턴은 Git ref를 다시 포함합니다.

다음 워크플로는 releases/10 또는 releases/beta/mona를 대상으로 하는 끌어오기 요청에 대한 pull_request 이벤트에서 실행되지만 !releases/**-alpha 부정 패턴이 긍정 패턴 이후에 나오므로 releases/10-alpha 또는 releases/beta/3-alpha를 대상으로 하는 끌어오기 요청에 대해서는 그러지 않습니다.

on:
  pull_request:
    branches:    
      - 'releases/**'
      - '!releases/**-alpha'

필터를 사용하여 푸시 이벤트에 특정 분기 또는 태그를 대상으로 지정

push 이벤트를 사용하는 경우 특정 분기 또는 태그에서 실행되도록 워크플로를 구성할 수 있습니다.

분기 이름 패턴을 포함하려는 경우 또는 분기 이름 패턴을 포함하거나 제외하려는 경우 branches 필터를 사용합니다. 분기 이름 패턴만 제외하려는 경우 branches-ignore 필터를 사용합니다. 워크플로의 동일한 이벤트에 대해 branches 필터와 branches-ignore 필터 둘 다는 사용할 수 없습니다.

태그 이름 패턴을 포함하려는 경우 또는 태그 이름 패턴을 포함하거나 제외하려는 경우 tags 필터를 사용합니다. 태그 이름 패턴만 제외하려는 경우 tags-ignore 필터를 사용합니다. 워크플로의 동일한 이벤트에 대해 tags 필터와 tags-ignore 필터 둘 다는 사용할 수 없습니다.

tags/tags-ignore만 정의하거나 branches/branches-ignore만 정의하는 경우 워크플로는 정의되지 않은 Git 참조에 영향을 주는 이벤트에 대해 실행되지 않습니다. tags/tags-ignore 및 branches/branches-ignore를 모두 정의하지 않는 경우 워크플로는 분기 또는 태그에 영향을 주는 이벤트에 대해 실행됩니다. 및 를 paths/paths-ignore모두 branches/branches-ignore 정의하는 경우 두 필터가 모두 충족될 때만 워크플로가 실행됩니다.

branches, branches-ignore, tags 및 tags-ignore 키워드는 두 개 이상의 분기 또는 태그 이름과 일치하도록 *, **, +, ?, ! 등의 문자를 사용하는 GLOB 패턴을 허용합니다. 이름에 해당 문자가 포함되어 있고 리터럴 일치를 원하는 경우 각 특수 문자를 \로 이스케이프해야 합니다. glob 패턴에 대한 자세한 내용은 "GitHub Actions에 대한 워크플로 구문"을 참조하세요.

예: 분기 및 태그 포함

branches 및 tags에 정의된 패턴은 Git 참조의 이름을 기준으로 평가됩니다. 예를 들어, 다음 워크플로는 push 이벤트가 있을 때마다 실행됩니다.

main으로 명명된 분기(refs/heads/main)
mona/octocat으로 명명된 분기(refs/heads/mona/octocat)
releases/10과 같이 이름이 releases/로 시작하는 분기(refs/heads/releases/10)
v2 태그(refs/tags/v2)
v1.9.1처럼 이름이 v1.으로 시작하는 태그(refs/tags/v1.9.1)

on:
  push:
    # Sequence of patterns matched against refs/heads
    branches:    
      - main
      - 'mona/octocat'
      - 'releases/**'
    # Sequence of patterns matched against refs/tags
    tags:        
      - v2
      - v1.*

예: 분기 및 태그 제외

패턴이 branches-ignore 또는 tags-ignore 패턴과 일치하면 워크플로가 실행되지 않습니다. branches 및 tags에 정의된 패턴은 Git 참조의 이름을 기준으로 평가됩니다. 예를 들어, push 이벤트가 다음을 대상으로 하지 않는 한 push 이벤트가 있을 때마다 다음 워크플로가 실행됩니다.

mona/octocat으로 명명된 분기(refs/heads/mona/octocat)
beta/3-alpha와 같이 이름이 releases/**-alpha와 일치하는 분기(refs/releases/beta/3-alpha)
v2 태그(refs/tags/v2)
v1.9처럼 이름이 v1.으로 시작하는 태그(refs/tags/v1.9)

on:
  push:
    # Sequence of patterns matched against refs/heads
    branches-ignore:    
      - 'mona/octocat'
      - 'releases/**-alpha'
    # Sequence of patterns matched against refs/tags
    tags-ignore:        
      - v2
      - v1.*

예: 분기 및 태그 포함 및 제외

단일 워크플로에서 동일한 이벤트를 필터링하는 데는 branches 및 branches-ignore를 사용할 수 없습니다. 마찬가지로 단일 워크플로에서 동일한 이벤트를 필터링하는 데는 tags 및 tags-ignore를 사용할 수 없습니다. 단일 이벤트에 대한 분기 또는 태그 패턴을 포함하거나 제외하려면 branches 또는 tags 필터를 ! 문자와 함께 사용하여 제외해야 하는 분기 또는 태그를 나타냅니다.

! 문자를 사용하여 분기를 정의하는 경우 ! 문자 없이 하나 이상의 분기도 정의해야 합니다. 분기만 제외하려면 branches-ignore를 대신 사용합니다. 마찬가지로 ! 문자를 사용하여 태그를 정의하는 경우 ! 문자 없이 하나 이상의 태그도 정의해야 합니다. 태그만 제외하려면 대신 tags-ignore를 사용합니다.

패턴을 정의하는 순서가 중요합니다.

긍정 일치 후 일치하는 부정 패턴(접두사 !)은 Git ref를 제외합니다.
부정 일치 후 일치하는 긍정 패턴은 Git ref를 다시 포함합니다.

부정 패턴 !releases/**-alpha는 긍정 패턴을 따르므로 다음 워크플로는 releases/10 또는 releases/beta/mona에 대한 푸시에서 실행되지만 releases/10-alpha 또는 releases/beta/3-alpha에서는 실행되지 않습니다.

on:
  push:
    branches:
      - 'releases/**'
      - '!releases/**-alpha'

필터를 사용하여 끌어오기 요청 또는 푸시 이벤트에 특정 경로를 대상으로 지정

push 및 pull_request 이벤트를 사용하는 경우 변경된 파일 경로에 따라 실행되도록 워크플로를 구성할 수 있습니다. 경로 필터는 태그 푸시에 대해 평가되지 않습니다.

파일 경로 패턴을 포함하려는 경우 또는 파일 경로 패턴을 포함 및 제외하려는 경우 paths 필터를 사용합니다. 파일 경로 패턴만 제외하려는 경우 paths-ignore 필터를 사용합니다. 워크플로의 동일한 이벤트에 대해 paths 필터와 paths-ignore 필터 둘 다는 사용할 수 없습니다.

및 를paths-ignore``paths/ 모두 branches/branches-ignore 정의하는 경우 워크플로는 두 필터가 모두 충족될 때만 실행됩니다.

paths 및 paths-ignore 키워드는 둘 이상의 경로 이름에 대한 일치 판정을 위해 * 및 ** 와일드카드 문자를 사용하는 GLOB 패턴을 허용합니다. 자세한 내용은 "GitHub Actions에 대한 워크플로 구문"을 참조하세요.

예: 경로 포함

하나 이상의 경로가 paths 필터의 패턴과 일치하면 워크플로가 실행됩니다. 예를 들어 JavaScript 파일(.js)을 푸시할 때마다 다음 워크플로가 실행됩니다.

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

참고: 경로 필터링, 분기 필터링 또는 커밋 메시지로 인해 워크플로를 건너뛰는 경우 해당 워크플로와 연결된 검사는 “보류 중” 상태로 유지됩니다. 이러한 검사가 성공해야 하는 끌어오기 요청은 병합에서 차단됩니다. 자세한 내용은 "필수 상태 검사 문제 해결"을 참조하세요.

예: 경로 제외

모든 경로 이름이 paths-ignore의 패턴과 일치하면 워크플로가 실행되지 않습니다. 경로 이름이 paths-ignore의 패턴과 일치하지 않는 경우 일부 경로 이름이 패턴과 일치하더라도 워크플로가 실행됩니다.

다음 경로 필터가 있는 워크플로는 리포지토리의 루트에 있는 docs 디렉터리 외부에 하나 이상의 파일이 포함된 push 이벤트에서만 실행됩니다.

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

예: 경로 포함 및 제외

paths 및 paths-ignore를 사용하여 단일 워크플로의 동일한 이벤트를 필터링할 수 없습니다. 단일 이벤트에 대한 경로 패턴을 포함 및 제외하려면 ! 문자와 함께 paths 필터를 사용하여 제외해야 하는 경로를 나타냅니다.

! 문자를 사용하여 경로를 정의하는 경우 ! 문자 없이 하나 이상의 경로도 정의해야 합니다. 경로만 제외하려면 paths-ignore를 대신 사용합니다.

패턴을 정의하는 순서가 중요합니다.

긍정 일치 후 일치하는 부정 패턴(접두사 !)은 경로를 제외합니다.
부정 일치 후 일치하는 긍정 패턴은 경로를 다시 포함합니다.

이 예제에서는 sub-project/docs 디렉터리에 파일이 없는 한 push 이벤트가 sub-project 디렉터리 또는 해당 하위 디렉터리에 파일을 포함할 때마다 실행됩니다. 예를 들어 sub-project/index.js 또는 sub-project/src/index.js를 변경한 푸시는 워크플로 실행을 트리거하지만, sub-project/docs/readme.md만 변경하는 푸시는 그러지 않습니다.

on:
  push:
    paths:
      - 'sub-project/**'
      - '!sub-project/docs/**'

Git 차이 비교

참고: 1,000개를 초과하는 커밋을 푸시하거나 GitHub가 시간 제한으로 인해 차이를 생성하지 않는 경우 워크플로가 항상 실행됩니다.

필터는 변경된 파일을 평가하고 paths-ignore 또는 paths 목록에 따라 이를 실행하여 워크플로 실행 여부를 결정합니다. 변경된 파일이 없으면 워크플로가 실행되지 않습니다.

GitHub는 푸시에는 2개의 점 차이를, 끌어오기 요청에는 3개의 점 차이를 사용하여 변경된 파일 목록을 생성합니다.

끌어오기 요청: 세 개의 점 차이는 토픽 분기의 최신 버전과 토픽 분기가 기본 분기와 마지막으로 동기화된 커밋을 비교한 것입니다.
기존 분기로 푸시: 두 개의 점 차이는 헤드와 기본 SHA를 서로 직접 비교합니다.
새 분기로 푸시: 푸시된 가장 깊은 커밋의 상위 부모에 대한 두 개의 점 차이입니다.

차이는 300개의 파일로 제한됩니다. 필터에서 반환된 처음 300개 파일에서 일치하지 않는 파일이 변경된 경우 워크플로가 실행되지 않습니다. 워크플로가 자동으로 실행되도록 보다 구체적인 필터를 만들어야 할 수 있습니다.

자세한 내용은 "끌어오기 요청의 분기 비교 정보"을 참조하세요.

필터를 사용하여 워크플로 실행 이벤트에 특정 분기를 대상으로 지정

workflow_run 이벤트를 사용하는 경우 워크플로를 트리거하기 위해 트리거 워크플로를 실행해야 하는 분기를 지정할 수 있습니다.

branches 및 branches-ignore 필터는 *, **, +, ?, ! 및 그 외 두 개 이상의 분기 이름에 대한 일치 판정을 위한 문자 등의 문자를 사용하는 GLOB 패턴을 허용합니다. 이름에 해당 문자가 포함되어 있고 리터럴 일치를 원하는 경우 각 특수 문자를 \로 이스케이프해야 합니다. glob 패턴에 대한 자세한 내용은 "GitHub Actions에 대한 워크플로 구문"을 참조하세요.

예를 들어 다음 트리거가 있는 워크플로는 이름이 releases/로 시작하는 분기에서 Build라는 워크플로가 실행되는 경우에만 실행됩니다.

on:
  workflow_run:
    workflows: ["Build"]
    types: [requested]
    branches:
      - 'releases/**'

다음 트리거가 있는 워크플로는 이름이 canary가 아닌 분기에서 Build라는 워크플로가 실행되는 경우에만 실행됩니다.

on:
  workflow_run:
    workflows: ["Build"]
    types: [requested]
    branches-ignore:
      - "canary"

워크플로의 동일한 이벤트에 대해 branches 필터와 branches-ignore 필터 둘 다는 사용할 수 없습니다. 단일 이벤트에 대한 분기 패턴을 포함 및 제외하려면 ! 문자와 함께 branches 필터를 사용하여 제외해야 하는 분기를 나타냅니다.

패턴을 정의하는 순서가 중요합니다.

긍정 일치 후 일치하는 부정 패턴(접두사 !)은 분기를 제외합니다.
부정 일치 후 일치하는 긍정 패턴은 분기를 다시 포함합니다.

예를 들어 다음 트리거가 있는 워크플로는 이름이 releases/10 또는 releases/beta/mona인 분기에서 Build라는 워크플로가 실행되는 경우에만 실행되며 분기 이름이 releases/10-alpha, releases/beta/3-alpha 또는 main인 경우에는 그러지 않습니다.

on:
  workflow_run:
    workflows: ["Build"]
    types: [requested]
    branches:
      - 'releases/**'
      - '!releases/**-alpha'

수동으로 트리거된 워크플로에 대한 입력 정의

workflow_dispatch 이벤트를 사용할 때 필요에 따라 워크플로에 전달되는 입력을 지정할 수 있습니다. 트리거된 워크플로는 github.event.inputs 컨텍스트에서 입력을 받습니다. 자세한 내용은 “컨텍스트”를 참조하세요.

on:
 workflow_dispatch:
   inputs:
     logLevel:
       description: 'Log level'
       required: true
       default: 'warning'
       type: choice
       options:
         - info
         - warning
         - debug
     print_tags:
       description: 'True to print to STDOUT'
       required: true
       type: boolean
     tags:
       description: 'Test scenario tags'
       required: true
       type: string
     environment:
       description: 'Environment to run tests against'
       type: environment
       required: true

jobs:
 print-tag:
   runs-on: ubuntu-latest
   if:  ${{ github.event.inputs.print_tags == 'true' }} 
   steps:
     - name: Print the input tag to STDOUT
       run: echo  The tags are ${{ github.event.inputs.tags }}

재사용 가능한 워크플로에 대한 입력, 출력, 비밀 정의

참고: 재사용 가능한 워크플로는 현재 베타 버전이며 변경될 수 있습니다.

재사용 가능한 워크플로가 호출 워크플로에서 받아야 하는 입력 및 비밀을 정의할 수 있습니다. 재사용 가능한 워크플로가 호출 워크플로에 사용할 수 있도록 하는 출력을 지정할 수도 있습니다. 자세한 내용은 "워크플로 다시 사용"을 참조하세요.

이벤트 정보 사용

워크플로 실행을 트리거한 이벤트에 대한 정보는 github.event 컨텍스트를 참조하세요. github.event 컨텍스트의 속성은 워크플로를 트리거한 이벤트 유형에 따라 달라집니다. 예를 들어 이슈에 레이블이 지정되면 트리거되는 워크플로에는 이슈 및 레이블에 대한 정보가 있습니다.

이벤트의 모든 속성 보기

일반적인 속성 및 예제 페이로드에 대한 웹후크 이벤트 설명서를 참조하세요. 자세한 내용은 "웹후크 이벤트 및 페이로드"을 참조하세요.

전체 github.event 컨텍스트를 인쇄하여 워크플로를 트리거한 이벤트에 사용할 수 있는 속성을 확인할 수도 있습니다.

jobs:
  print_context:
    runs-on: ubuntu-latest
    steps:
      - env:
          EVENT_CONTEXT: ${{ toJSON(github.event) }}
        run: |
          echo $EVENT_CONTEXT

이벤트 속성 액세스 및 사용

워크플로의 github.event 컨텍스트를 사용할 수 있습니다. 예를 들어 package*.json, .github/CODEOWNERS 또는 .github/workflows/**를 변경하는 끌어오기 요청이 열리면 다음 워크플로가 실행됩니다. 끌어오기 요청 작성자(github.event.pull_request.user.login)가 octobot 또한 dependabot[bot]이 아닌 경우 워크플로는 GitHub CLI를 사용하여 끌어오기 요청(github.event.pull_request.number)에 레이블을 지정하고 주석을 적용합니다.

on:
  pull_request:
    types:
      - opened
    paths:
      - '.github/workflows/**'
      - '.github/CODEOWNERS'
      - 'package*.json'

jobs:
  triage:
    if: >-
      github.event.pull_request.user.login != 'octobot' &&
      github.event.pull_request.user.login != 'dependabot[bot]'
    runs-on: ubuntu-latest
    steps:
      - name: "Comment about changes we can't accept"
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          PR: ${{ github.event.pull_request.html_url }}
        run: |
          gh pr edit $PR --add-label 'invalid'
          gh pr comment $PR --body 'It looks like you edited `package*.json`, `.github/CODEOWNERS`, or `.github/workflows/**`. We do not allow contributions to these files. Please review our [contributing guidelines](https://github.com/octo-org/octo-repo/blob/main/CONTRIBUTING.md) for what contributions are accepted.'

컨텍스트에 대한 자세한 내용은 "컨텍스트"을 참조하세요. 이벤트 페이로드에 대한 자세한 내용은 "웹후크 이벤트 및 페이로드"을 참조하세요.

워크플로 실행 방법 추가 제어

이벤트, 이벤트 작업 유형 또는 이벤트 필터가 제공하는 것보다 더 세부적인 제어를 원하는 경우 조건부 및 환경을 사용하여 워크플로의 개별 작업 또는 단계가 실행될지 여부를 제어할 수 있습니다.

조건부 사용

조건부를 사용하여 워크플로의 작업 또는 단계 실행 여부를 추가로 제어할 수 있습니다.

이벤트 페이로드에서 값을 사용하는 예제

예를 들어 이슈에 특정 레이블이 추가될 때 워크플로를 실행하려면 issues labeled 이벤트 작업 유형에서 트리거하고 조건부를 사용하여 워크플로를 트리거한 레이블을 확인할 수 있습니다. 다음 워크플로는 워크플로 리포지토리의 이슈에 레이블이 추가될 때 실행되지만 레이블에 bug라는 이름이 지정된 경우에만 run_if_label_matches 작업이 실행됩니다.

on:
  issues:
    types:
      - labeled

jobs:
  run_if_label_matches:
    if: github.event.label.name == 'bug'
    runs-on: ubuntu-latest
    steps:
      - run: echo 'The label was bug'

이벤트 유형을 사용하는 예제

예를 들어 워크플로를 트리거한 이벤트에 따라 다른 작업 또는 단계를 실행하려는 경우 조건부를 사용하여 이벤트 컨텍스트에 특정 이벤트 유형이 있는지 확인할 수 있습니다. 이슈 또는 끌어오기 요청이 종결될 때마다 다음 워크플로가 실행됩니다. 이슈가 종결되었기 때문에 워크플로가 실행된 경우 github.event 컨텍스트에 issue에 대한 값은 포함되지만 pull_request에 대한 값은 포함되지 않습니다. 따라서 if_issue 단계가 실행되지만 if_pr 단계는 실행되지 않습니다. 반대로 끌어오기 요청이 종결되어 워크플로가 실행되면 if_pr 단계가 실행되지만 if_issue 단계가 실행되지 않습니다.

on:
  issues:
    types:
      - closed
  pull_request:
    types:
      - closed

jobs:
  state_event_type:
    runs-on: ubuntu-latest
    steps:
    - name: if_issue
      if: github.event.issue
      run: |
        echo An issue was closed
    - name: if_pr
      if: github.event.pull_request
      run: |
        echo A pull request was closed

이벤트 컨텍스트에서 사용할 수 있는 정보에 대한 자세한 내용은 “이벤트 정보 사용”을 참조하세요. 조건부를 사용하는 방법에 대한 자세한 내용은 "식"을 참조하세요.

환경을 사용하여 워크플로 작업을 수동으로 트리거

워크플로에서 특정 작업을 수동으로 트리거하려는 경우 특정 팀 또는 사용자의 승인이 필요한 환경을 사용할 수 있습니다. 먼저 필요한 검토자를 사용하여 환경을 구성합니다. 자세한 내용은 "배포에 환경 사용"을 참조하세요. 그런 다음, environment: 키를 사용하여 워크플로 작업에서 환경 이름을 참조합니다. 환경을 참조하는 모든 작업은 하나 이상의 검토자가 작업을 승인할 때까지 실행되지 않습니다.

예를 들어 다음 워크플로는 main에 대한 푸시가 있을 때마다 실행됩니다. build 작업은 항상 실행됩니다. publish 작업은 build 작업이 성공적으로 완료된 후와(원인: needs: [build])production 환경에 대한 모든 규칙이 통과된 후(원인: environment: production)에만 실행됩니다.

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: build
        echo 'building'

  publish:
    needs: [build]
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: publish
        echo 'publishing'

환경, 환경 비밀, 환경 보호 규칙은 모든 제품의 퍼블릭 리포지토리에서 사용할 수 있습니다. 프라이빗 또는 내부 리포지토리의 환경, 환경 비밀 및 배포 분기에 액세스하려면 GitHub Pro, GitHub Team, GitHub Enterprise를 사용해야 합니다. 프라이빗 또는 내부 리포지토리의 기타 환경 보호 규칙에 액세스하려면 GitHub Enterprise를 사용해야 합니다.

사용 가능한 이벤트

사용 가능한 이벤트의 전체 목록은 "워크플로를 트리거하는 이벤트"을 참조하세요.

워크플로 트리거

이 문서의 내용