# 워크플로를 트리거하는 이벤트

특정 활동이 GitHub 발생할 때, 예약된 시간에 또는 외부 GitHub 이벤트가 발생할 때 실행되도록 워크플로를 구성할 수 있습니다.

## 워크플로를 트리거하는 이벤트 정보

워크플로 트리거는 워크플로를 실행하게 하는 이벤트입니다. 워크플로 트리거 사용법에 대한 자세한 내용은 [워크플로우 시작](/ko/actions/how-tos/write-workflows/choose-when-workflows-run/trigger-a-workflow)을 참고하세요.

일부 이벤트에는 여러 작업 유형이 있습니다. 해당 이벤트의 경우 워크플로 실행을 트리거할 작업 유형을 지정할 수 있습니다. 각 활동 유형의 의미에 대한 자세한 내용은 [웹후크 이벤트 및 페이로드](/ko/webhooks/webhook-events-and-payloads)에서 확인하세요.

> \[!NOTE]
> 모든 웹후크 이벤트가 워크플로를 트리거하는 것은 아닙니다.

## `branch_protection_rule`

| 웹후크 이벤트 페이로드                                                                                | 활동 유형                                      | `GITHUB_SHA`  | `GITHUB_REF` |
| ------------------------------------------------------------------------------------------- | ------------------------------------------ | ------------- | ------------ |
| [`branch_protection_rule`](/ko/webhooks/webhook-events-and-payloads#branch_protection_rule) | - `created`<br/>- `edited`<br/>- `deleted` | 기본 분기의 마지막 커밋 | 기본 분기        |

> \[!NOTE]
> \*
> 둘 이상의 활동 유형이 이 이벤트를 트리거합니다. 각 활동 유형에 대한 자세한 내용은 [웹후크 이벤트 및 페이로드](/ko/webhooks/webhook-events-and-payloads#branch_protection_rule)을 참조하세요. 기본적으로 모든 활동 유형은 이 이벤트에서 실행되는 워크플로를 트리거합니다.
> `types` 키워드를 사용하여 워크플로 실행을 특정 활동 유형으로 제한할 수 있습니다. 자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)을(를) 참조하세요.
>
> * 이 이벤트는 워크플로 파일이 기본 분기에 있는 경우에만 워크플로 실행을 트리거합니다.

워크플로 리포지토리의 분기 보호 규칙이 변경되면 워크플로를 실행합니다. 분기 보호 규칙에 대한 자세한 내용은 [보호된 분기 정보](/ko/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)을(를) 참조하세요. 브랜치 보호 규칙 API에 대한 자세한 내용은 GraphQL API 설명서의 [Branches](/ko/graphql/reference/branches#object-branchprotectionrule) 섹션이나 [브랜치 및 설정에 대한 REST API 엔드포인트](/ko/rest/branches)를 참고하세요.

예를 들어 분기 보호 규칙이 `created` 또는 `deleted` 상태인 경우 워크플로를 실행할 수 있습니다.

```yaml
on:
  branch_protection_rule:
    types: [created, deleted]
```

## `check_run`

| 웹후크 이벤트 페이로드                                                      | 활동 유형                                                                      | `GITHUB_SHA`  | `GITHUB_REF` |
| ----------------------------------------------------------------- | -------------------------------------------------------------------------- | ------------- | ------------ |
| [`check_run`](/ko/webhooks/webhook-events-and-payloads#check_run) | - `created`<br/>- `rerequested`<br/>- `completed`<br/>- `requested_action` | 기본 분기의 마지막 커밋 | 기본 분기        |

> \[!NOTE]
> \*
> 둘 이상의 활동 유형이 이 이벤트를 트리거합니다. 각 활동 유형에 대한 자세한 내용은 [웹후크 이벤트 및 페이로드](/ko/webhooks/webhook-events-and-payloads#check_run)을 참조하세요. 기본적으로 모든 활동 유형은 이 이벤트에서 실행되는 워크플로를 트리거합니다.
> `types` 키워드를 사용하여 워크플로 실행을 특정 활동 유형으로 제한할 수 있습니다. 자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)을(를) 참조하세요.
>
> * 이 이벤트는 워크플로 파일이 기본 분기에 있는 경우에만 워크플로 실행을 트리거합니다.
> * 재귀 워크플로를 방지하기 위해, 이 이벤트는 검사 실행의 검사 도구 모음이 GitHub Actions에 의해 생성된 경우 또는 검사 도구 모음의 헤드 SHA가 GitHub Actions에 연결된 경우에는 워크플로를 트리거하지 않습니다.

검사 실행과 관련된 작업이 발생할 때 워크플로를 실행합니다. 검사 실행은 검사 도구 모음의 일부인 개별 테스트입니다. 자세한 내용은 [REST API를 사용하여 검사와 상호작용하기](/ko/rest/guides/using-the-rest-api-to-interact-with-checks)을 참조하세요. 검사 실행 API에 대한 자세한 내용은 GraphQL API 설명서의 [수표](/ko/graphql/reference/checks#object-checkrun) 또는 [검사 실행에 대한 REST API 엔드포인트](/ko/rest/checks/runs)을(를) 참조하세요.

예를 들어 검사 실행이 `rerequested` 또는 `completed`된 경우 워크플로를 실행할 수 있습니다.

```yaml
on:
  check_run:
    types: [rerequested, completed]
```

## `check_suite`

| 웹후크 이벤트 페이로드                                                          | 활동 유형         | `GITHUB_SHA`  | `GITHUB_REF` |
| --------------------------------------------------------------------- | ------------- | ------------- | ------------ |
| [`check_suite`](/ko/webhooks/webhook-events-and-payloads#check_suite) | - `completed` | 기본 분기의 마지막 커밋 | 기본 분기        |

> \[!NOTE]
> \*
> 둘 이상의 활동 유형이 이 이벤트를 트리거합니다. 각 활동 유형에 대한 자세한 내용은 [웹후크 이벤트 및 페이로드](/ko/webhooks/webhook-events-and-payloads#check_suite)을 참조하세요.
> `completed` 작업 유형만 지원되지만 작업 유형을 지정하면 나중에 더 많은 작업 형식이 추가될 경우 워크플로가 특정 상태로 유지됩니다. 기본적으로 모든 활동 유형은 이 이벤트에서 실행되는 워크플로를 트리거합니다.
> `types` 키워드를 사용하여 워크플로 실행을 특정 활동 유형으로 제한할 수 있습니다. 자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)을(를) 참조하세요.
>
> * 이 이벤트는 워크플로 파일이 기본 분기에 있는 경우에만 워크플로 실행을 트리거합니다.
> * 재귀 워크플로를 방지하기 위해 이 이벤트는 확인 도구 모음을 만든 GitHub Actions 경우 또는 Check Suite의 헤드 SHA가 연결된 GitHub Actions경우 워크플로를 트리거하지 않습니다.

검사 도구 모음 작업이 발생할 때 워크플로를 실행합니다. 검사 도구 모음은 특정 커밋에 대해 생성된 검사 실행의 컬렉션입니다. 검사 도구 모음은 도구 모음에 있는 검사 실행의 상태와 결론을 요약합니다. 자세한 내용은 [REST API를 사용하여 검사와 상호작용하기](/ko/rest/guides/using-the-rest-api-to-interact-with-checks)을 참조하세요. 검사 실행 API에 대한 자세한 내용은 GraphQL API 설명서의 [수표](/ko/graphql/reference/checks#object-checksuite) 또는 [검사 도구 모음에 대한 REST API 엔드포인트](/ko/rest/checks/suites)을(를) 참조하세요.

예를 들어 검사 도구 모음이 `completed`된 경우 워크플로를 실행할 수 있습니다.

```yaml
on:
  check_suite:
    types: [completed]
```

## `create`

| 웹후크 이벤트 페이로드                                                | 활동 유형 | `GITHUB_SHA`           | `GITHUB_REF` |
| ----------------------------------------------------------- | ----- | ---------------------- | ------------ |
| [`create`](/ko/webhooks/webhook-events-and-payloads#create) | 해당 없음 | 만든 분기 또는 태그에 대한 마지막 커밋 | 만든 분기 또는 태그  |

> \[!NOTE]
> 태그를 세 개 이상 동시에 생성할 경우 이벤트가 발생하지 않습니다.

누군가가 워크플로의 리포지토리에서 Git 참조(Git 분기 또는 태그)를 만들 때 워크플로를 실행합니다. Git 참조를 만들기 위한 API에 대한 자세한 내용은 GraphQL API 설명서의 [Git](/ko/graphql/reference/git#mutation-createref) 또는 [Git 참조에 대한 REST API 엔드포인트](/ko/rest/git/refs#create-a-reference)을(를) 참조하세요.

예를 들어 `create` 이벤트가 발생할 때 워크플로를 실행할 수 있습니다.

```yaml
on:
  create
```

## `delete`

| 웹후크 이벤트 페이로드                                                | 활동 유형 | `GITHUB_SHA`  | `GITHUB_REF` |
| ----------------------------------------------------------- | ----- | ------------- | ------------ |
| [`delete`](/ko/webhooks/webhook-events-and-payloads#delete) | 해당 없음 | 기본 분기의 마지막 커밋 | 기본 분기        |

> \[!NOTE]
>
> * 이 이벤트는 워크플로 파일이 기본 분기에 있는 경우에만 워크플로 실행을 트리거합니다.
> * 태그를 세 개 이상 동시에 삭제할 경우 이벤트가 발생하지 않습니다.

누군가가 워크플로의 리포지토리에서 Git 참조(Git 분기 또는 태그)를 삭제할 때 워크플로를 실행합니다. Git 참조를 삭제하기 위한 API에 대한 자세한 내용은 GraphQL API 설명서의 [Git](/ko/graphql/reference/git#mutation-deleteref) 또는 [Git 참조에 대한 REST API 엔드포인트](/ko/rest/git/refs#delete-a-reference)을(를) 참조하세요.

예를 들어 `delete` 이벤트가 발생할 때 워크플로를 실행할 수 있습니다.

```yaml
on:
  delete
```

## `deployment`

| 웹후크 이벤트 페이로드                                                        | 활동 유형 | `GITHUB_SHA` | `GITHUB_REF`                           |
| ------------------------------------------------------------------- | ----- | ------------ | -------------------------------------- |
| [`deployment`](/ko/webhooks/webhook-events-and-payloads#deployment) | 해당 없음 | 배포할 커밋       | 배포할 분기 또는 태그(커밋 SHA를 사용하여 만든 경우 비어 있음) |

누군가가 워크플로의 리포지토리에서 배포를 만들 때 워크플로를 실행합니다. 커밋 SHA를 사용하여 생성된 배포에는 Git 참조가 없을 수 있습니다. Git 참조를 만들기 위한 API에 대한 자세한 내용은 GraphQL API 설명서의 [Deployments](/ko/graphql/reference/deployments#mutation-createdeployment) 또는 [리포지토리에 대한 REST API 엔드포인트](/ko/rest/repos#deployments)을(를) 참조하세요.

예를 들어 `deployment` 이벤트가 발생할 때 워크플로를 실행할 수 있습니다.

```yaml
on:
  deployment
```

## `deployment_status`

| 웹후크 이벤트 페이로드                                                                      | 활동 유형 | `GITHUB_SHA` | `GITHUB_REF`               |
| --------------------------------------------------------------------------------- | ----- | ------------ | -------------------------- |
| [`deployment_status`](/ko/webhooks/webhook-events-and-payloads#deployment_status) | 해당 없음 | 배포할 커밋       | 배포할 분기 또는 태그(커밋할 경우 비어 있음) |

> \[!NOTE]
> 배포 상태가 `inactive`로 설정된 경우, 워크플로 실행이 트리거되지 않습니다.

타사에서 배포 상태를 제공하는 경우 워크플로를 실행합니다. 커밋 SHA를 사용하여 생성된 배포에는 Git 참조가 없을 수 있습니다. 배포 상태를 만들기 위한 API에 대한 자세한 내용은 GraphQL API 설명서의 [Deployments](/ko/graphql/reference/deployments#mutation-createdeploymentstatus) 또는 [배포에 대한 REST API 엔드포인트](/ko/rest/deployments#create-a-deployment-status)을(를) 참조하세요.

예를 들어 `deployment_status` 이벤트가 발생할 때 워크플로를 실행할 수 있습니다.

```yaml
on:
  deployment_status
```

## `discussion`

| 웹후크 이벤트 페이로드                                                        | 활동 유형                                                                                                                                                                                                                           | `GITHUB_SHA`  | `GITHUB_REF` |
| ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------- | ------------ |
| [`discussion`](/ko/webhooks/webhook-events-and-payloads#discussion) | - `created`<br/>- `edited`<br/>- `deleted`<br/>- `transferred`<br/>- `pinned`<br/>- `unpinned`<br/>- `labeled`<br/>- `unlabeled`<br/>- `locked`<br/>- `unlocked`<br/>- `category_changed`<br/> - `answered`<br/> - `unanswered` | 기본 분기의 마지막 커밋 | 기본 분기        |

> \[!NOTE]
> \*
> 둘 이상의 활동 유형이 이 이벤트를 트리거합니다. 각 활동 유형에 대한 자세한 내용은 [웹후크 이벤트 및 페이로드](/ko/webhooks/webhook-events-and-payloads#discussion)을 참조하세요. 기본적으로 모든 활동 유형은 이 이벤트에서 실행되는 워크플로를 트리거합니다.
> `types` 키워드를 사용하여 워크플로 실행을 특정 활동 유형으로 제한할 수 있습니다. 자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)을(를) 참조하세요.
>
> * 이 이벤트는 워크플로 파일이 기본 분기에 있는 경우에만 워크플로 실행을 트리거합니다.
> * GitHub Discussions에 대한 웹후크 이벤트는 현재 공개 미리 보기 버전이며 변경될 수 있습니다.

워크플로의 리포지토리에서 토론이 만들어지거나 수정될 때 워크플로를 실행합니다. 토론 댓글과 관련된 작업을 처리할 때는 [`discussion_comment`](#discussion_comment) 이벤트를 사용합니다. 토론에 관한 자세한 내용은 [토론에 대한 정보](/ko/discussions/collaborating-with-your-community-using-discussions/about-discussions) 항목을 참조하세요. GraphQL API에 대한 자세한 내용은 [토론](/ko/graphql/reference/discussions#object-discussion)을(를) 참조하세요.

예를 들어 토론이 `created`, `edited` 또는 `answered` 된 경우 워크플로를 실행할 수 있습니다.

```yaml
on:
  discussion:
    types: [created, edited, answered]
```

## `discussion_comment`

| 웹후크 이벤트 페이로드                                                                        | 활동 유형                                           | `GITHUB_SHA`  | `GITHUB_REF` |
| ----------------------------------------------------------------------------------- | ----------------------------------------------- | ------------- | ------------ |
| [`discussion_comment`](/ko/webhooks/webhook-events-and-payloads#discussion_comment) | - `created`<br/>- `edited`<br/>- `deleted`<br/> | 기본 분기의 마지막 커밋 | 기본 분기        |

> \[!NOTE]
> \*
> 둘 이상의 활동 유형이 이 이벤트를 트리거합니다. 각 활동 유형에 대한 자세한 내용은 [웹후크 이벤트 및 페이로드](/ko/webhooks/webhook-events-and-payloads#discussion_comment)을 참조하세요. 기본적으로 모든 활동 유형은 이 이벤트에서 실행되는 워크플로를 트리거합니다.
> `types` 키워드를 사용하여 워크플로 실행을 특정 활동 유형으로 제한할 수 있습니다. 자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)을(를) 참조하세요.
>
> * 이 이벤트는 워크플로 파일이 기본 분기에 있는 경우에만 워크플로 실행을 트리거합니다.
> * GitHub Discussions에 대한 웹후크 이벤트는 현재 공개 미리 보기 버전이며 변경될 수 있습니다.

워크플로의 리포지토리에서 토론의 댓글이 만들어지거나 수정될 때 워크플로를 실행합니다. 토론 댓글 외에 토론 관련 작업을 할 경우 [`discussion`](#discussion) 이벤트를 사용합니다. 토론에 관한 자세한 내용은 [토론에 대한 정보](/ko/discussions/collaborating-with-your-community-using-discussions/about-discussions) 항목을 참조하세요. GraphQL API에 대한 자세한 내용은 [토론](/ko/graphql/reference/discussions#object-discussion)을(를) 참조하세요.

예를 들어 토론 댓글이 `created` 또는 `deleted`된 경우 워크플로를 실행할 수 있습니다.

```yaml
on:
  discussion_comment:
    types: [created, deleted]
```

## `fork`

| 웹후크 이벤트 페이로드                                            | 활동 유형 | `GITHUB_SHA`  | `GITHUB_REF` |
| ------------------------------------------------------- | ----- | ------------- | ------------ |
| [`fork`](/ko/webhooks/webhook-events-and-payloads#fork) | 해당 없음 | 기본 분기의 마지막 커밋 | 기본 분기        |

> \[!NOTE]
> 이 이벤트는 워크플로 파일이 기본 분기에 있는 경우에만 워크플로 실행을 트리거합니다.

누군가가 리포지토리를 포크할 때 워크플로를 실행합니다. REST API에 대한 자세한 내용은 [포크에 대한 REST API 엔드포인트](/ko/rest/repos/forks#create-a-fork)을(를) 참조하세요.

예를 들어 `fork` 이벤트가 발생할 때 워크플로를 실행할 수 있습니다.

```yaml
on:
  fork
```

## `gollum`

| 웹후크 이벤트 페이로드                                                | 활동 유형 | `GITHUB_SHA`  | `GITHUB_REF` |
| ----------------------------------------------------------- | ----- | ------------- | ------------ |
| [`gollum`](/ko/webhooks/webhook-events-and-payloads#gollum) | 해당 없음 | 기본 분기의 마지막 커밋 | 기본 분기        |

> \[!NOTE]
> 이 이벤트는 워크플로 파일이 기본 분기에 있는 경우에만 워크플로 실행을 트리거합니다.

누군가가 Wiki 페이지를 만들거나 업데이트할 때 워크플로를 실행합니다. 자세한 내용은 [위키 정보](/ko/communities/documenting-your-project-with-wikis/about-wikis)을(를) 참조하세요.

예를 들어 `gollum` 이벤트가 발생할 때 워크플로를 실행할 수 있습니다.

```yaml
on:
  gollum
```

## `image_version`

| 웹후크 이벤트 페이로드 | 활동 유형 | `GITHUB_SHA`  | `GITHUB_REF` |
| ------------ | ----- | ------------- | ------------ |
| 해당 없음        | 해당 없음 | 기본 분기의 마지막 커밋 | 기본 분기        |

지정된 이미지의 새 버전을 사용할 수 있게 되면 워크플로를 실행합니다. 이 이벤트는 일반적으로 이미지 버전을 성공적으로 만든 후에 트리거되므로 새 이미지 버전에 대한 응답으로 배포 또는 알림과 같은 작업을 자동화할 수 있습니다.

이 이벤트는 이미지 이름과 버전 모두에 대해 glob 패턴을 지원합니다. 아래 예제는 새 이미지 버전이 지정된 이름 및 버전 조합과 일치하는 경우 트리거됩니다. 예: `["MyNewImage", 1.0.0]`, `["MyNewImage", 2.53.0]`, `["MyOtherImage", 1.0.0]`및 `["MyOtherImage", 2.0.0]`.

```yaml
on:
  image_version:
    names:
    - "MyNewImage"
    - "MyOtherImage"
    versions:
    - 1.*
    - 2.*
```

## `issue_comment`

| 웹후크 이벤트 페이로드                                                              | 활동 유형                                           | `GITHUB_SHA`  | `GITHUB_REF` |
| ------------------------------------------------------------------------- | ----------------------------------------------- | ------------- | ------------ |
| [`issue_comment`](/ko/webhooks/webhook-events-and-payloads#issue_comment) | - `created`<br/>- `edited`<br/>- `deleted`<br/> | 기본 분기의 마지막 커밋 | 기본 분기        |

> \[!NOTE]
> \*
> 둘 이상의 활동 유형이 이 이벤트를 트리거합니다. 각 활동 유형에 대한 자세한 내용은 [웹후크 이벤트 및 페이로드](/ko/webhooks/webhook-events-and-payloads#issue_comment)을 참조하세요. 기본적으로 모든 활동 유형은 이 이벤트에서 실행되는 워크플로를 트리거합니다.
> `types` 키워드를 사용하여 워크플로 실행을 특정 활동 유형으로 제한할 수 있습니다. 자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)을(를) 참조하세요.
>
> * 이 이벤트는 워크플로 파일이 기본 분기에 있는 경우에만 워크플로 실행을 트리거합니다.

문제 또는 끌어오기 요청 설명이 생성, 편집 또는 삭제될 때 워크플로를 실행합니다. 이슈 댓글 API에 대한 자세한 내용은 GraphQL API 설명서의 [이슈](/ko/graphql/reference/issues#object-issuecomment) 또는 REST API 설명서의 [웹후크 이벤트 및 페이로드](/ko/webhooks/webhook-events-and-payloads#issue_comment)을(를) 참조하세요.

예를 들어 문제 또는 끌어오기 요청 설명이 `created` 또는 `deleted`된 경우 워크플로를 실행할 수 있습니다.

```yaml
on:
  issue_comment:
    types: [created, deleted]
```

### 문제 전용 또는 끌어오기 요청 전용 `issue_comment`

`issue_comment` 이벤트는 문제 및 끌어오기 요청 모두에 대한 설명에 대해 발생합니다. 조건에서 `github.event.issue.pull_request` 속성을 사용하여 트리거하는 개체가 문제인지 끌어오기 요청인지에 따라 다른 작업을 수행할 수 있습니다.

예를 들어 이 워크플로는 `pr_commented` 이벤트가 끌어오기 요청에서 시작된 경우에만 `issue_comment` 작업을 실행합니다.
`issue_commented` 이벤트가 문제에서 시작된 경우에만 `issue_comment` 작업을 실행합니다.

```yaml
on: issue_comment

jobs:
  pr_commented:
    # This job only runs for pull request comments
    name: PR comment
    if: ${{ github.event.issue.pull_request }}
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo A comment on PR $NUMBER
        env:
          NUMBER: ${{ github.event.issue.number }}

  issue_commented:
    # This job only runs for issue comments
    name: Issue comment
    if: ${{ !github.event.issue.pull_request }}
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo A comment on issue $NUMBER
        env:
          NUMBER: ${{ github.event.issue.number }}
```

## `issues`

| 웹후크 이벤트 페이로드                                                | 활동 유형                                                                                                                                                                                                                                                                                                                                                    | `GITHUB_SHA`  | `GITHUB_REF` |
| ----------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------- | ------------ |
| [`issues`](/ko/webhooks/webhook-events-and-payloads#issues) | - `opened`<br/>- `edited`<br/>- `deleted`<br/>- `transferred`<br/>- `pinned`<br/>- `unpinned`<br/>- `closed`<br/>- `reopened`<br/>- `assigned`<br/>- `unassigned`<br/>- `labeled`<br/>- `unlabeled`<br/>- `locked`<br/>- `unlocked`<br/>- `milestoned`<br/> - `demilestoned`<br/> - `typed`<br/> - `untyped`<br/> - `field_added`<br/> - `field_removed` | 기본 분기의 마지막 커밋 | 기본 분기        |

> \[!NOTE]
> \*
> 둘 이상의 활동 유형이 이 이벤트를 트리거합니다. 각 활동 유형에 대한 자세한 내용은 [웹후크 이벤트 및 페이로드](/ko/webhooks/webhook-events-and-payloads#issues)을 참조하세요. 기본적으로 모든 활동 유형은 이 이벤트에서 실행되는 워크플로를 트리거합니다.
> `types` 키워드를 사용하여 워크플로 실행을 특정 활동 유형으로 제한할 수 있습니다. 자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)을(를) 참조하세요.
>
> * 이 이벤트는 워크플로 파일이 기본 분기에 있는 경우에만 워크플로 실행을 트리거합니다.

워크플로의 리포지토리에서 문제가 만들어지거나 수정될 때 워크플로를 실행합니다. 문제 설명과 관련된 작업에서는 [`issue_comment`](#issue_comment) 이벤트를 활용합니다. 이슈에 관한 자세한 내용은 [문제 개요](/ko/issues/tracking-your-work-with-issues/learning-about-issues/about-issues) 항목을 참조하세요. 이슈 API에 대한 자세한 내용은 GraphQL API 설명서의 [이슈](/ko/graphql/reference/issues#object-issue) 또는 [이슈에 대한 REST API 엔드포인트](/ko/rest/issues)을(를) 참조하세요.

예를 들어 문제가 `opened`, `edited` 또는 `milestoned`된 경우 워크플로를 실행할 수 있습니다.

```yaml
on:
  issues:
    types: [opened, edited, milestoned]
```

문제 필드 값이 설정, 변경 또는 지워지면 워크플로를 실행할 수도 있습니다.
`field_added` 활동 유형은 필드 값이 처음 설정될 때와 기존 값이 업데이트될 때 모두 트리거됩니다.
`field_removed` 활동 유형은 필드 값이 지워질 때 실행됩니다.

```yaml
on:
  issues:
    types: [field_added, field_removed]
```

## `label`

| 웹후크 이벤트 페이로드                                              | 활동 유형                                           | `GITHUB_SHA`  | `GITHUB_REF` |
| --------------------------------------------------------- | ----------------------------------------------- | ------------- | ------------ |
| [`label`](/ko/webhooks/webhook-events-and-payloads#label) | - `created`<br/>- `edited`<br/>- `deleted`<br/> | 기본 분기의 마지막 커밋 | 기본 분기        |

> \[!NOTE]
> \*
> 둘 이상의 활동 유형이 이 이벤트를 트리거합니다. 각 활동 유형에 대한 자세한 내용은 [웹후크 이벤트 및 페이로드](/ko/webhooks/webhook-events-and-payloads#label)을 참조하세요. 기본적으로 모든 활동 유형은 이 이벤트에서 실행되는 워크플로를 트리거합니다.
> `types` 키워드를 사용하여 워크플로 실행을 특정 활동 유형으로 제한할 수 있습니다. 자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)을(를) 참조하세요.
>
> * 이 이벤트는 워크플로 파일이 기본 분기에 있는 경우에만 워크플로 실행을 트리거합니다.

워크플로의 리포지토리에서 레이블이 만들어지거나 수정될 때 워크플로를 실행합니다. 레이블에 관한 자세한 내용은 [레이블 관리](/ko/issues/using-labels-and-milestones-to-track-work/managing-labels) 항목을 참조하세요. 레이블 API에 대한 자세한 내용은 GraphQL API 설명서의 [이슈](/ko/graphql/reference/issues#object-label) 또는 [레이블에 대한 REST API 엔드포인트](/ko/rest/issues/labels)을(를) 참조하세요.

문제, 끌어오기 요청 또는 토론에 레이블이 추가되거나 제거될 경우 워크플로를 실행하려면 `labeled`, `unlabeled`, `issues` 또는 [](#issues) 이벤트 대신 `pull_request` 또는 [](#pull_request) 작업 유형을 사용하는 것이 좋습니다.

예를 들어 레이블이 `created` 또는 `deleted`된 경우 워크플로를 실행할 수 있습니다.

```yaml
on:
  label:
    types: [created, deleted]
```

## `merge_group`

| 웹후크 이벤트 페이로드                                                          | 활동 유형              | `GITHUB_SHA` | `GITHUB_REF` |
| --------------------------------------------------------------------- | ------------------ | ------------ | ------------ |
| [`merge_group`](/ko/webhooks/webhook-events-and-payloads#merge_group) | `checks_requested` | 병합 그룹의 SHA   | 병합 그룹의 참조    |

> \[!NOTE]
>
> *

둘 이상의 활동 유형이 이 이벤트를 트리거합니다. 활동 유형만 `checks_requested` 지원되지만 나중에 더 많은 활동 유형이 추가될 경우 활동 유형을 지정하면 워크플로가 구체적으로 유지됩니다. 각 활동 유형에 대한 자세한 내용은 [웹후크 이벤트 및 페이로드](/ko/webhooks/webhook-events-and-payloads#merge_group)을(를) 참조하세요. 기본적으로 모든 활동 유형은 이 이벤트에서 실행되는 워크플로를 트리거합니다.
`types` 키워드를 사용하여 워크플로 실행을 특정 활동 유형으로 제한할 수 있습니다. 자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)을(를) 참조하세요.

> * 리포지토리에서 GitHub Actions을(를) 사용하여 필요한 검사 을(를) 통해 워크플로가 필요한 경우 `merge_group` 이벤트를 추가 트리거로 포함하도록 워크플로를 업데이트해야 합니다. 그렇지 않으면 병합 큐에 끌어오기 요청을 추가할 때 상태 검사가 트리거되지 않습니다. 상태 확인 필요가 보고되지 않으므로 병합이 실패합니다. `merge_group` 이벤트는 `pull_request` 및 `push` 이벤트트와 별개입니다.

끌어오기 요청이 병합 큐에 추가되면 워크플로를 실행합니다. 그러면 병합 그룹에 끌어오기 요청이 추가됩니다. 자세한 내용은 [끌어오기 요청을 병합 대기열과 병합하기](/ko/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request-with-a-merge-queue)을(를) 참조하세요.

예를 들어 `checks_requested` 작업이 발생한 경우 워크플로를 실행할 수 있습니다.

```yaml
on:
  pull_request:
    branches: [ "main" ]
  merge_group:
    types: [checks_requested]
```

## `milestone`

| 웹후크 이벤트 페이로드                                                      | 활동 유형                                                                         | `GITHUB_SHA`  | `GITHUB_REF` |
| ----------------------------------------------------------------- | ----------------------------------------------------------------------------- | ------------- | ------------ |
| [`milestone`](/ko/webhooks/webhook-events-and-payloads#milestone) | - `created`<br/>- `closed`<br/>- `opened`<br/>- `edited`<br/>- `deleted`<br/> | 기본 분기의 마지막 커밋 | 기본 분기        |

> \[!NOTE]
> \*
> 둘 이상의 활동 유형이 이 이벤트를 트리거합니다. 각 활동 유형에 대한 자세한 내용은 [웹후크 이벤트 및 페이로드](/ko/webhooks/webhook-events-and-payloads#milestone)을 참조하세요. 기본적으로 모든 활동 유형은 이 이벤트에서 실행되는 워크플로를 트리거합니다.
> `types` 키워드를 사용하여 워크플로 실행을 특정 활동 유형으로 제한할 수 있습니다. 자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)을(를) 참조하세요.
>
> * 이 이벤트는 워크플로 파일이 기본 분기에 있는 경우에만 워크플로 실행을 트리거합니다.

워크플로의 리포지토리에서 마일스톤이 만들어지거나 수정될 때 워크플로를 실행합니다. 마일스톤에 관한 자세한 내용은 [마일스톤 정보](/ko/issues/using-labels-and-milestones-to-track-work/about-milestones) 항목을 참조하세요. 마일스톤 API에 대한 자세한 내용은 GraphQL API 설명서의 [이슈](/ko/graphql/reference/issues#object-milestone) 또는 [마일스톤에 대한 REST API 엔드포인트](/ko/rest/issues/milestones)을(를) 참조하세요.

마일스톤에 문제가 추가되거나 제거될 때 워크플로를 실행하려면 `milestoned` 이벤트 대신 `demilestoned` 또는 `issues` 작업 유형을 사용하는 것이 좋습니다.

예를 들어 마일스톤이 `opened` 또는 `deleted`된 경우 워크플로를 실행할 수 있습니다.

```yaml
on:
  milestone:
    types: [opened, deleted]
```

## `page_build`

| 웹후크 이벤트 페이로드                                                        | 활동 유형 | `GITHUB_SHA`  | `GITHUB_REF` |
| ------------------------------------------------------------------- | ----- | ------------- | ------------ |
| [`page_build`](/ko/webhooks/webhook-events-and-payloads#page_build) | 해당 없음 | 기본 분기의 마지막 커밋 | 기본 분기        |

> \[!NOTE]
> 이 이벤트는 워크플로 파일이 기본 분기에 있는 경우에만 워크플로 실행을 트리거합니다.

리포지토리에서 GitHub Pages가 활성화된 경우, 누군가 GitHub Pages의 원본 게시인 분기에 커밋을 푸시하면 이 워크플로가 실행됩니다. 게시 소스에 대한 GitHub Pages 자세한 내용은 [GitHub Pages 사이트의 게시 소스 구성](/ko/pages/getting-started-with-github-pages/configuring-a-publishing-source-for-your-github-pages-site)을 참조하세요. REST API에 대한 자세한 내용은 [리포지토리에 대한 REST API 엔드포인트](/ko/rest/repos#pages)을(를) 참조하세요.

예를 들어 `page_build` 이벤트가 발생할 때 워크플로를 실행할 수 있습니다.

```yaml
on:
  page_build
```

## `public`

| 웹후크 이벤트 페이로드                                                | 활동 유형 | `GITHUB_SHA`  | `GITHUB_REF` |
| ----------------------------------------------------------- | ----- | ------------- | ------------ |
| [`public`](/ko/webhooks/webhook-events-and-payloads#public) | 해당 없음 | 기본 분기의 마지막 커밋 | 기본 분기        |

> \[!NOTE]
> 이 이벤트는 워크플로 파일이 기본 분기에 있는 경우에만 워크플로 실행을 트리거합니다.

워크플로의 리포지토리가 프라이빗에서 퍼블릭으로 변경되면 워크플로를 실행합니다. REST API에 대한 자세한 내용은 [리포지토리에 대한 REST API 엔드포인트](/ko/rest/repos#edit)을(를) 참조하세요.

예를 들어 `public` 이벤트가 발생할 때 워크플로를 실행할 수 있습니다.

```yaml
on:
  public
```

## `pull_request`

| 웹후크 이벤트 페이로드                                                            | 활동 유형                                                                                                                                                                                                                                                                                                                                                                                                                            | `GITHUB_SHA` | `GITHUB_REF` |
| ----------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ | ------------ |
| [`pull_request`](/ko/webhooks/webhook-events-and-payloads#pull_request) | - `assigned`<br/>- `unassigned`<br/>- `labeled`<br/>- `unlabeled`<br/>- `opened`<br/>- `edited`<br/>- `closed`<br/>- `reopened`<br/>- `synchronize`<br/>- `converted_to_draft`<br/>- `locked`<br/>- `unlocked`<br/>- `enqueued`<br/>- `dequeued`<br/>- `milestoned`<br/>- `demilestoned`<br/>- `ready_for_review`<br/>- `review_requested`<br/>- `review_request_removed`<br/>- `auto_merge_enabled`<br/>- `auto_merge_disabled` |              |              |
| `GITHUB_REF` 분기의 마지막 병합 커밋                                              | PR 병합 분기 `refs/pull/PULL_REQUEST_NUMBER/merge`                                                                                                                                                                                                                                                                                                                                                                                   |              |              |

> \[!NOTE]
> \*
> 둘 이상의 활동 유형이 이 이벤트를 트리거합니다. 각 활동 유형에 대한 자세한 내용은 [웹후크 이벤트 및 페이로드](/ko/webhooks/webhook-events-and-payloads#pull_request)을 참조하세요. 기본적으로 워크플로는 `pull_request` 이벤트의 작업 유형이 `opened`, `synchronize` 또는 `reopened`인 경우에만 실행됩니다. 다양한 작업 유형별로 워크플로를 트리거하려면 `types` 키워드를 사용합니다. 자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)을(를) 참조하세요.
>
> * 병합 충돌이 있는 풀 리퀘스트가 있는 경우 워크플로는 `pull_request` 작업에서 실행되지 않습니다. 병합 충돌을 먼저 해결해야 합니다. 반대로 끌어오기 요청에 병합 충돌이 있는 경우에도 `pull_request_target` 이벤트가 있는 워크플로가 실행됩니다.
>   `pull_request_target` 트리거를 사용하기 전에 보안 위험을 알고 있어야 합니다. 자세한 내용은 [`pull_request_target`](#pull_request_target)를 참조하세요.
> *

`pull_request` 웹후크 이벤트 페이로드는 병합된 풀 리퀘스트와 포크된 리포지토리에서 온 풀 리퀘스트의 경우 비어 있습니다.

> * 워크플로가 `GITHUB_TOKEN`를 사용하여 풀 리퀘스트를 생성하거나 업데이트하는 경우, `pull_request`, `opened`, 또는 `synchronize` 활동 유형의 `reopened` 이벤트는 승인이 필요한 워크플로 실행을 생성합니다. 리포지토리에 대한 쓰기 권한이 있는 사용자는 끌어오기 요청 페이지에서 이러한 실행을 승인할 수 있습니다.
>   `workflow_dispatch` 및 `repository_dispatch`를 제외하면, 그 외 `GITHUB_TOKEN`에 의해 트리거되는 이벤트는 워크플로 실행을 전혀 생성하지 않습니다.
> * 종료된 풀 리퀘스트의 `GITHUB_REF` 값은 해당 풀 리퀘스트가 병합되었는지 여부에 따라 달라집니다. 병합되지 않고 풀 리퀘스트가 종료되면 `refs/pull/PULL_REQUEST_NUMBER/merge`이 됩니다. 병합된 결과로 풀 리퀘스트가 종료되면, 병합된 분기는 `ref` 와 같이 정규화됩니다. 예를 들어 `/refs/heads/main` 와 같습니다.

워크플로 리포지토리의 끌어오기 요청에 대한 작업이 발생할 때 워크플로를 실행합니다. 예를 들어 작업 형식이 지정되지 않은 경우 끌어오기 요청이 열리거나 다시 열리거나 끌어오기 요청의 헤드 분기가 업데이트될 때 워크플로가 실행됩니다. 끌어오기 요청 검토, 끌어오기 요청 검토 주석 또는 끌어오기 요청 주석과 관련된 작업의 경우 [`pull_request_review`](#pull_request_review), [`pull_request_review_comment`](#pull_request_review_comment), 또는 [`issue_comment`](#issue_comment) 이벤트를 대신 사용합니다. 풀 리퀘스트 API에 대한 자세한 내용은 GraphQL API 설명서의 [끌어오기 요청](/ko/graphql/reference/pulls#object-pullrequest) 또는 [끌어오기 요청에 대한 REST API 엔드포인트](/ko/rest/pulls)을(를) 참조하세요.

이 이벤트의 `GITHUB_SHA`는 끌어오기 요청 병합 분기의 마지막 병합 커밋입니다. 끌어오기 요청 헤드 분기의 마지막 커밋에 대한 커밋 ID를 가져오려면 `github.event.pull_request.head.sha`를 대신 사용합니다. 병합 분기에 대한 자세한 내용은 [끌어오기 요청](/ko/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#pull-request-refs-and-merge-branches)을 참조하세요.

### 병합 분기가 워크플로에 미치는 영향

열려 있는 병합 가능한 끌어오기 요청의 경우, `pull_request` 이벤트에 의해 트리거되는 워크플로가 `GITHUB_REF`를 병합 분기로 설정됩니다.
`actions/checkout`는 기본적으로 `GITHUB_REF`를 사용하기 때문에 병합 브랜치를 체크아웃합니다. CI 테스트는 헤드 분기뿐만 아니라 병합된 결과를 기준으로 실행됩니다.

* `GITHUB_REF`이(가) `refs/pull/PULL_REQUEST_NUMBER/merge`로 설정됩니다.
* `GITHUB_SHA` 는 병합 분기에서 병합 커밋의 SHA입니다.

병합을 시뮬레이션하지 않고 헤드 분기 커밋만 테스트하려면 워크플로에서 사용하여 `github.event.pull_request.head.sha` 헤드 분기를 확인합니다.

예를 들어 끌어오기 요청을 열거나 다시 열 때 워크플로를 실행할 수 있습니다.

```yaml
on:
  pull_request:
    types: [opened, reopened]
```

이벤트 컨텍스트를 사용하여 워크플로의 작업이 실행되는 시기를 추가로 제어할 수 있습니다. 예를 들어 이 워크플로는 끌어오기 요청에 대한 검토가 요청될 때 실행되지만 `specific_review_requested`에 의한 검토가 요청된 경우에만 `octo-team` 작업이 실행됩니다.

```yaml
on:
  pull_request:
    types: [review_requested]
jobs:
  specific_review_requested:
    runs-on: ubuntu-latest
    if: ${{ github.event.requested_team.name == 'octo-team'}}
    steps:
      - run: echo 'A review from octo-team was requested'
```

### `pull_request` 워크플로는 풀 리퀘스트의 헤드 또는 베이스 분기를 기반으로 실행됩니다.

`branches` 또는 `branches-ignore` 필터를 사용하여 특정 분기를 대상으로 하는 끌어오기 요청에서만 실행되도록 워크플로를 구성할 수 있습니다. 자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/reference/workflows-and-actions/workflow-syntax#onpull_requestpull_request_targetbranchesbranches-ignore)을(를) 참조하세요.

예를 들어 이 워크플로는 이름이 `releases/`로 시작하는 분기를 대상으로 하는 끌어오기 요청을 열 때 실행됩니다.

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

> \[!NOTE]
> `branches` 필터와 `paths` 필터를 둘 다 사용하는 경우 두 필터가 모두 충족될 때만 워크플로가 실행됩니다.예를 들어 다음 워크플로는 이름이 다음으로 시작하는 분기에서 JavaScript(`.js`) 파일의 변경 내용이 포함된 끌어오기 요청이 열려 있는 경우에만 실행됩니다.`releases/`
>
> ```yaml
> on:
>   pull_request:
>     types:
>       - opened
>     branches:
>       - 'releases/**'
>     paths:
>       - '**.js'
> ```

(끌어오기 요청의 베이스 분기 이름이 아닌) 끌어오기 요청의 헤드 분기 이름에 따라 작업을 실행하려면 조건부에서 `github.head_ref` 컨텍스트를 사용합니다. 예를 들어 이 워크플로는 끌어오기 요청이 열릴 때마다 실행되지만 끌어오기 요청의 헤드가 이름이 `run_if`로 시작하는 분기인 경우에만 `releases/` 작업이 실행됩니다.

```yaml
on:
  pull_request:
    types:
      - opened
jobs:
  run_if:
    if: startsWith(github.head_ref, 'releases/')
    runs-on: ubuntu-latest
    steps:
      - run: echo "The head of this PR starts with 'releases/'"
```

### `pull_request` 워크플로는 풀 리퀘스트에서 변경된 파일을 기준으로 실행됩니다.

끌어오기 요청이 특정 파일을 변경할 때 실행되도록 워크플로를 구성할 수도 있습니다. 자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore)을(를) 참조하세요.

예를 들어 끌어오기 요청에 JavaScript 파일(`.js`) 변경 내용이 포함된 경우 이 워크플로가 실행됩니다.

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

> \[!NOTE]
> `branches` 필터와 `paths` 필터를 둘 다 사용하는 경우 두 필터가 모두 충족될 때만 워크플로가 실행됩니다.예를 들어 다음 워크플로는 이름이 다음으로 시작하는 분기에서 JavaScript(`.js`) 파일의 변경 내용이 포함된 끌어오기 요청이 열려 있는 경우에만 실행됩니다.`releases/`
>
> ```yaml
> on:
>   pull_request:
>     types:
>       - opened
>     branches:
>       - 'releases/**'
>     paths:
>       - '**.js'
> ```

### 끌어오기 요청 병합 시 `pull_request` 워크플로 실행

끌어오기 요청이 병합되면 끌어오기 요청이 자동으로 닫힙니다.
`pull_request`
`closed` 이벤트 형식을 사용하여 끌어오기 요청이 병합될 경우 워크플로가 실행되도록 설정하고, `merged` 이벤트 값을 확인하는 조건을 설정합니다. 예를 들어 끌어오기 요청이 닫힐 때마다 다음 워크플로가 실행됩니다. 끌어오기 요청도 병합된 경우에만 `if_merged` 작업이 실행됩니다.

```yaml
on:
  pull_request:
    types:
      - closed

jobs:
  if_merged:
    if: github.event.pull_request.merged == true
    runs-on: ubuntu-latest
    steps:
    - run: |
        echo The PR was merged
```

#### 포크된 리포지토리의 워크플로

워크플로는 기본적으로 포크된 리포지토리에서 실행되지 않습니다. 포크된 리포지토리의 **Actions**(작업) 탭에서 GitHub Actions를 사용하도록 설정해야 합니다.

`GITHUB_TOKEN`의 예외를 제외하고 포크된 리포지토리에서 워크플로가 트리거될 때 비밀이 실행기에게 전달되지 않습니다. `GITHUB_TOKEN`에는 포크된 리포지토리 끌어오기 요청의 읽기 전용 권한이 있습니다. 자세한 내용은 [워크플로에서 인증에 GITHUB\_TOKEN 사용](/ko/actions/security-guides/automatic-token-authentication)을(를) 참조하세요.

#### 포크된 리포지토리에 대한 끌어오기 요청 이벤트

포크된 리포지토리에서 기본 리포지토리로의 끌어오기 요청의 경우 GitHub는 기본 리포지토리에 `pull_request`, `issue_comment`, `pull_request_review_comment`, `pull_request_review`, `pull_request_target` 이벤트를 보냅니다. 포크된 리포지토리에서는 끌어오기 요청 이벤트가 발생하지 않습니다.

처음으로 참가자가 퍼블릭 리포지토리에 끌어오기 요청을 제출하는 경우, 끌어오기 요청에 대해 쓰기 액세스 권한이 있는 유지 관리자가 실행 중인 워크플로를 승인해야 할 수 있습니다. 자세한 내용은 [포크에서 시작된 워크플로 실행을 승인하기](/ko/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks)을(를) 참조하세요.

포크된 리포지토리에서 프라이빗 리포지토리로 끌어오기 요청은 워크플로가 활성화 상태일 때만 실행됩니다. [리포지토리에 대한 GitHub Actions 설정 관리](/ko/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-forks-of-private-repositories)을(를) 참조하세요.

> \[!NOTE]
> Dependabot 끌어오기 요청으로 트리거되는 워크플로는 포크된 리포지토리에서 온 것처럼 처리되며 관련 제한 사항도 적용됩니다.

## `pull_request_comment` (사용 `issue_comment`)

끌어오기 요청의 diff가 아닌, 끌어오기 요청 자체에 대한 주석이 생성, 편집 또는 삭제될 때 워크플로를 실행하려면 [`issue_comment`](#issue_comment) 이벤트를 사용하세요. 끌어오기 요청 검토 또는 끌어오기 요청 검토 주석과 관련된 활동의 경우 [`pull_request_review`](#pull_request_review) 또는 [`pull_request_review_comment`](#pull_request_review_comment) 이벤트를 대신 사용합니다.

## `pull_request_review`

| 웹후크 이벤트 페이로드                                                                          | 활동 유형                                          | `GITHUB_SHA` | `GITHUB_REF` |
| ------------------------------------------------------------------------------------- | ---------------------------------------------- | ------------ | ------------ |
| [`pull_request_review`](/ko/webhooks/webhook-events-and-payloads#pull_request_review) | - `submitted`<br/>- `edited`<br/>- `dismissed` |              |              |
| `GITHUB_REF` 분기의 마지막 병합 커밋                                                            | PR 병합 분기 `refs/pull/PULL_REQUEST_NUMBER/merge` |              |              |

> \[!NOTE]
> 둘 이상의 활동 유형이 이 이벤트를 트리거합니다. 각 활동 유형에 대한 자세한 내용은 [웹후크 이벤트 및 페이로드](/ko/webhooks/webhook-events-and-payloads#pull_request_review)을 참조하세요. 기본적으로 모든 활동 유형은 이 이벤트에서 실행되는 워크플로를 트리거합니다.
> `types` 키워드를 사용하여 워크플로 실행을 특정 활동 유형으로 제한할 수 있습니다. 자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)을(를) 참조하세요.

끌어오기 요청 검토가 제출되거나 편집되거나 해제될 때 워크플로를 실행합니다. 끌어오기 요청 검토는 본문 주석 및 상태 외에도 끌어오기 요청 검토 주석 그룹입니다. 끌어오기 요청 검토 주석 또는 끌어오기 요청 주석과 관련된 활동의 경우 [`pull_request_review_comment`](#pull_request_review_comment) 또는 [`issue_comment`](#issue_comment) 이벤트를 대신 사용합니다. 풀 리퀘스트 리뷰 API에 대한 자세한 내용은 GraphQL API 설명서의 [끌어오기 요청](/ko/graphql/reference/pulls#object-pullrequest) 또는 [끌어오기 요청에 대한 REST API 엔드포인트](/ko/rest/pulls#reviews)을(를) 참조하세요.

예를 들어 끌어오기 요청 검토가 `edited` 또는 `dismissed`될 때 워크플로를 실행할 수 있습니다.

```yaml
on:
  pull_request_review:
    types: [edited, dismissed]
```

### 끌어오기 요청이 승인될 때 워크플로 실행

끌어오기 요청이 승인되었을 때 워크플로를 실행하려면 `submitted` 이벤트 유형으로 워크플로를 `pull_request_review` 트리거한 다음 `github.event.review.state` 속성으로 검토 상태를 확인할 수 있습니다. 예를 들어 이 워크플로는 끌어오기 요청 검토가 제출될 때마다 실행되지만 제출된 검토가 승인 검토인 경우에만 `approved` 작업이 실행됩니다.

```yaml
on:
  pull_request_review:
    types: [submitted]

jobs:
  approved:
    if: github.event.review.state == 'approved'
    runs-on: ubuntu-latest
    steps:
      - run: echo "This PR was approved"
```

#### 포크된 리포지토리의 워크플로

워크플로는 기본적으로 포크된 리포지토리에서 실행되지 않습니다. 포크된 리포지토리의 **Actions**(작업) 탭에서 GitHub Actions를 사용하도록 설정해야 합니다.

`GITHUB_TOKEN`의 예외를 제외하고 포크된 리포지토리에서 워크플로가 트리거될 때 비밀이 실행기에게 전달되지 않습니다. `GITHUB_TOKEN`에는 포크된 리포지토리 끌어오기 요청의 읽기 전용 권한이 있습니다. 자세한 내용은 [워크플로에서 인증에 GITHUB\_TOKEN 사용](/ko/actions/security-guides/automatic-token-authentication)을(를) 참조하세요.

#### 포크된 리포지토리에 대한 끌어오기 요청 이벤트

포크된 리포지토리에서 기본 리포지토리로의 끌어오기 요청의 경우 GitHub는 기본 리포지토리에 `pull_request`, `issue_comment`, `pull_request_review_comment`, `pull_request_review`, `pull_request_target` 이벤트를 보냅니다. 포크된 리포지토리에서는 끌어오기 요청 이벤트가 발생하지 않습니다.

처음으로 참가자가 퍼블릭 리포지토리에 끌어오기 요청을 제출하는 경우, 끌어오기 요청에 대해 쓰기 액세스 권한이 있는 유지 관리자가 실행 중인 워크플로를 승인해야 할 수 있습니다. 자세한 내용은 [포크에서 시작된 워크플로 실행을 승인하기](/ko/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks)을(를) 참조하세요.

포크된 리포지토리에서 프라이빗 리포지토리로 끌어오기 요청은 워크플로가 활성화 상태일 때만 실행됩니다. [리포지토리에 대한 GitHub Actions 설정 관리](/ko/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-forks-of-private-repositories)을(를) 참조하세요.

> \[!NOTE]
> Dependabot 끌어오기 요청으로 트리거되는 워크플로는 포크된 리포지토리에서 온 것처럼 처리되며 관련 제한 사항도 적용됩니다.

## `pull_request_review_comment`

| 웹후크 이벤트 페이로드                                                                                          | 활동 유형                                          | `GITHUB_SHA` | `GITHUB_REF` |
| ----------------------------------------------------------------------------------------------------- | ---------------------------------------------- | ------------ | ------------ |
| [`pull_request_review_comment`](/ko/webhooks/webhook-events-and-payloads#pull_request_review_comment) | - `created`<br/>- `edited`<br/>- `deleted`     |              |              |
| `GITHUB_REF` 분기의 마지막 병합 커밋                                                                            | PR 병합 분기 `refs/pull/PULL_REQUEST_NUMBER/merge` |              |              |

> \[!NOTE]
> 둘 이상의 활동 유형이 이 이벤트를 트리거합니다. 각 활동 유형에 대한 자세한 내용은 [웹후크 이벤트 및 페이로드](/ko/webhooks/webhook-events-and-payloads#pull_request_review_comment)을 참조하세요. 기본적으로 모든 활동 유형은 이 이벤트에서 실행되는 워크플로를 트리거합니다.
> `types` 키워드를 사용하여 워크플로 실행을 특정 활동 유형으로 제한할 수 있습니다. 자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)을(를) 참조하세요.

끌어오기 요청 검토 주석이 수정되면 워크플로를 실행합니다. 끌어오기 요청 검토 주석은 끌어오기 요청의 diff에 대한 주석입니다. 끌어오기 요청 검토 또는 끌어오기 요청 주석과 관련된 활동의 경우 [`pull_request_review`](#pull_request_review) 또는 [`issue_comment`](#issue_comment) 이벤트를 대신 사용합니다. 풀 리퀘스트 리뷰 코멘트 API에 대한 자세한 내용은 GraphQL API 설명서의 [끌어오기 요청](/ko/graphql/reference/pulls#object-pullrequestreviewcomment) 또는 [끌어오기 요청에 대한 REST API 엔드포인트](/ko/rest/pulls#comments)을(를) 참조하세요.

예를 들어 끌어오기 요청 검토 주석이 `created` 또는 `deleted`될 때 워크플로를 실행할 수 있습니다.

```yaml
on:
  pull_request_review_comment:
    types: [created, deleted]
```

#### 포크된 리포지토리의 워크플로

워크플로는 기본적으로 포크된 리포지토리에서 실행되지 않습니다. 포크된 리포지토리의 **Actions**(작업) 탭에서 GitHub Actions를 사용하도록 설정해야 합니다.

`GITHUB_TOKEN`의 예외를 제외하고 포크된 리포지토리에서 워크플로가 트리거될 때 비밀이 실행기에게 전달되지 않습니다. `GITHUB_TOKEN`에는 포크된 리포지토리 끌어오기 요청의 읽기 전용 권한이 있습니다. 자세한 내용은 [워크플로에서 인증에 GITHUB\_TOKEN 사용](/ko/actions/security-guides/automatic-token-authentication)을(를) 참조하세요.

#### 포크된 리포지토리에 대한 끌어오기 요청 이벤트

포크된 리포지토리에서 기본 리포지토리로의 끌어오기 요청의 경우 GitHub는 기본 리포지토리에 `pull_request`, `issue_comment`, `pull_request_review_comment`, `pull_request_review`, `pull_request_target` 이벤트를 보냅니다. 포크된 리포지토리에서는 끌어오기 요청 이벤트가 발생하지 않습니다.

처음으로 참가자가 퍼블릭 리포지토리에 끌어오기 요청을 제출하는 경우, 끌어오기 요청에 대해 쓰기 액세스 권한이 있는 유지 관리자가 실행 중인 워크플로를 승인해야 할 수 있습니다. 자세한 내용은 [포크에서 시작된 워크플로 실행을 승인하기](/ko/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks)을(를) 참조하세요.

포크된 리포지토리에서 프라이빗 리포지토리로 끌어오기 요청은 워크플로가 활성화 상태일 때만 실행됩니다. [리포지토리에 대한 GitHub Actions 설정 관리](/ko/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-forks-of-private-repositories)을(를) 참조하세요.

> \[!NOTE]
> Dependabot 끌어오기 요청으로 트리거되는 워크플로는 포크된 리포지토리에서 온 것처럼 처리되며 관련 제한 사항도 적용됩니다.

## `pull_request_target`

| 웹후크 이벤트 페이로드                                                            | 활동 유형                                                                                                                                                                                                                                                                                                                                                                                                                            | `GITHUB_SHA`  | `GITHUB_REF` |
| ----------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------- | ------------ |
|                                                                         |                                                                                                                                                                                                                                                                                                                                                                                                                                  |               |              |
| [`pull_request`](/ko/webhooks/webhook-events-and-payloads#pull_request) | - `assigned`<br/>- `unassigned`<br/>- `labeled`<br/>- `unlabeled`<br/>- `opened`<br/>- `edited`<br/>- `closed`<br/>- `reopened`<br/>- `synchronize`<br/>- `converted_to_draft`<br/>- `locked`<br/>- `unlocked`<br/>- `enqueued`<br/>- `dequeued`<br/>- `milestoned`<br/>- `demilestoned`<br/>- `ready_for_review`<br/>- `review_requested`<br/>- `review_request_removed`<br/>- `auto_merge_enabled`<br/>- `auto_merge_disabled` | 기본 분기의 마지막 커밋 | 기본 분기        |
|                                                                         |                                                                                                                                                                                                                                                                                                                                                                                                                                  |               |              |

> \[!NOTE]
> 둘 이상의 활동 유형이 이 이벤트를 트리거합니다. 각 활동 유형에 대한 자세한 내용은 [웹후크 이벤트 및 페이로드](/ko/webhooks/webhook-events-and-payloads#pull_request)을 참조하세요. 기본적으로 워크플로는 `pull_request_target` 이벤트의 작업 유형이 `opened`, `synchronize` 또는 `reopened`인 경우에만 실행됩니다. 다양한 작업 유형별로 워크플로를 트리거하려면 `types` 키워드를 사용합니다. 자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)을(를) 참조하세요.

워크플로 리포지토리의 끌어오기 요청에 대한 작업이 발생할 때 워크플로를 실행합니다. 예를 들어 작업 형식이 지정되지 않은 경우 끌어오기 요청이 열리거나 다시 열리거나 끌어오기 요청의 헤드 분기가 업데이트될 때 워크플로가 실행됩니다.

이 이벤트는 끌어오기 요청의 베이스기본 리포지토리의 기본 분기`pull_request`의 컨텍스트에서 실행됩니다. 이렇게 하면 리포지토리를 변경하거나 워크플로에서 사용하는 비밀을 도용할 수 있는 끌어오기 요청의 헤드에서 안전하지 않은 코드가 실행되지 않습니다. 이 이벤트를 사용하면 워크플로에서 포크의 끌어오기 요청에 대한 레이블 또는 주석과 같은 작업을 수행할 수 있습니다. 끌어오기 요청에서 코드를 빌드하거나 실행해야 하는 경우 이 이벤트를 사용하지 마세요.

리포지토리 보안을 보장하기 위해 특정 패턴(예: SHA와 유사한 패턴)과 일치하는 이름을 가진 분기가 `pull_request_target` 이벤트 발생 시 워크플로를 트리거하지 않을 수 있습니다.

> \[!WARNING]
> `pull_request_target` 트리거에서 신뢰할 수 없는 코드를 실행하면 보안 취약성이 발생할 수 있습니다. 이러한 취약성에는 캐시 악용 및 쓰기 권한 또는 비밀에 대한 의도하지 않은 액세스 권한 부여가 포함됩니다. 이 트리거를 안전하게 사용하는 방법을 알아보려면 [pull\_request\_target 안전하게 사용](/ko/actions/reference/security/securely-using-pull_request_target)을 참조하세요. 기본 위험에 대한 자세한 내용은 [안전 사용 참조](/ko/enterprise-cloud@latest/actions/reference/security/secure-use#mitigating-the-risks-of-untrusted-code-checkout) 및 [pwn 요청 방지](https://securitylab.github.com/research/github-actions-preventing-pwn-requests) 를 참조하세요 GitHub Security Lab.

예를 들어 끌어오기 요청이 `assigned`, `opened`, `synchronize`, 또는 `reopened`될 때 워크플로를 실행할 수 있습니다.

```yaml
on:
  pull_request_target:
    types: [assigned, opened, synchronize, reopened]
```

### `pull_request_target` 워크플로는 풀 리퀘스트의 헤드 또는 베이스 분기를 기반으로 실행됩니다.

`branches` 또는 `branches-ignore` 필터를 사용하여 특정 분기를 대상으로 하는 끌어오기 요청에서만 실행되도록 워크플로를 구성할 수 있습니다. 자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/reference/workflows-and-actions/workflow-syntax#onpull_requestpull_request_targetbranchesbranches-ignore)을(를) 참조하세요.

예를 들어 이 워크플로는 이름이 `releases/`로 시작하는 분기를 대상으로 하는 끌어오기 요청을 열 때 실행됩니다.

```yaml
on:
  pull_request_target:
    types:
      - opened
    branches:
      - 'releases/**'
```

> \[!NOTE]
> `branches` 필터와 `paths` 필터를 둘 다 사용하는 경우 두 필터가 모두 충족될 때만 워크플로가 실행됩니다.예를 들어 다음 워크플로는 이름이 다음으로 시작하는 분기에서 JavaScript(`.js`) 파일의 변경 내용이 포함된 끌어오기 요청이 열려 있는 경우에만 실행됩니다.`releases/`
>
> ```yaml
> on:
>   pull_request_target:
>     types:
>       - opened
>     branches:
>       - 'releases/**'
>     paths:
>       - '**.js'
> ```

(끌어오기 요청의 베이스 분기 이름이 아닌) 끌어오기 요청의 헤드 분기 이름에 따라 작업을 실행하려면 조건부에서 `github.head_ref` 컨텍스트를 사용합니다. 예를 들어 이 워크플로는 끌어오기 요청이 열릴 때마다 실행되지만 끌어오기 요청의 헤드가 이름이 `run_if`로 시작하는 분기인 경우에만 `releases/` 작업이 실행됩니다.

```yaml
on:
  pull_request_target:
    types:
      - opened
jobs:
  run_if:
    if: startsWith(github.head_ref, 'releases/')
    runs-on: ubuntu-latest
    steps:
      - run: echo "The head of this PR starts with 'releases/'"
```

### `pull_request_target` 워크플로는 풀 리퀘스트에서 변경된 파일을 기준으로 실행됩니다.

끌어오기 요청이 특정 파일을 변경할 때 실행되도록 `paths` 또는 `paths-ignore` 필터를 사용하여 워크플로를 구성할 수도 있습니다. 자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore)을(를) 참조하세요.

예를 들어 끌어오기 요청에 JavaScript 파일(`.js`) 변경 내용이 포함된 경우 이 워크플로가 실행됩니다.

```yaml
on:
  pull_request_target:
    paths:
      - '**.js'
```

> \[!NOTE]
> `branches` 필터와 `paths` 필터를 둘 다 사용하는 경우 두 필터가 모두 충족될 때만 워크플로가 실행됩니다.예를 들어 다음 워크플로는 이름이 다음으로 시작하는 분기에서 JavaScript(`.js`) 파일의 변경 내용이 포함된 끌어오기 요청이 열려 있는 경우에만 실행됩니다.`releases/`
>
> ```yaml
> on:
>   pull_request_target:
>     types:
>       - opened
>     branches:
>       - 'releases/**'
>     paths:
>       - '**.js'
> ```

### 끌어오기 요청 병합 시 `pull_request_target` 워크플로 실행

끌어오기 요청이 병합되면 끌어오기 요청이 자동으로 닫힙니다.
`pull_request_target`
`closed` 이벤트 형식을 사용하여 끌어오기 요청이 병합될 경우 워크플로가 실행되도록 설정하고, `merged` 이벤트 값을 확인하는 조건을 설정합니다. 예를 들어 끌어오기 요청이 닫힐 때마다 다음 워크플로가 실행됩니다. 끌어오기 요청도 병합된 경우에만 `if_merged` 작업이 실행됩니다.

```yaml
on:
  pull_request_target:
    types:
      - closed

jobs:
  if_merged:
    if: github.event.pull_request.merged == true
    runs-on: ubuntu-latest
    steps:
    - run: |
        echo The PR was merged
```

## `push`

| 웹후크 이벤트 페이로드                                            | 활동 유형 | `GITHUB_SHA`                                                           | `GITHUB_REF` |
| ------------------------------------------------------- | ----- | ---------------------------------------------------------------------- | ------------ |
| [`push`](/ko/webhooks/webhook-events-and-payloads#push) | 해당 없음 | 팁 커밋이 참조로 푸시되었으며, 분기를 삭제하면 워크플로의 SHA 실행과 관련된 참조가 리포지토리의 기본 분기로 되돌아갑니다. | 업데이트된 참조     |

> \[!NOTE]
>
> * GitHub Actions 사용할 수 있는 웹후크 페이로드는 `added` 개체에 `removed`, `modified` 및 `commit` 특성을 포함하지 않습니다. API를 사용하여 전체 커밋 개체를 검색할 수 있습니다. 자세한 정보는 GraphQL API 설명서의 [커밋](/ko/graphql/reference/commits#object-commit) 또는 [커밋에 대한 REST API 엔드포인트](/ko/rest/commits#get-a-commit)을(를) 참조하세요.
> * 한 번에 5,000개 이상의 분기가 푸시되는 경우 이벤트가 생성되지 않습니다. 태그가 한 번에 세 개 이상 푸시되면 태그에 대한 이벤트가 생성되지 않습니다.

커밋 또는 태그를 푸시하거나 템플릿에서 리포지토리를 생성할 때 워크플로를 실행합니다. 여기에는 기본 분기에 병합되지 않은 워크플로가 포함됩니다. 자세한 내용은 [워크플로를 트리거하는 이벤트](/ko/actions/reference/workflows-and-actions/events-that-trigger-workflows#running-your-workflow-only-when-a-push-to-specific-branches-occurs)을(를) 참조하세요.

예를 들어 `push` 이벤트가 발생할 때 워크플로를 실행할 수 있습니다.

```yaml
on:
  push
```

> \[!NOTE]
> `push` 웹후크 이벤트가 워크플로 실행을 트리거할 때 작업 UI의 ‘푸시한 사람’ 필드에는 작성자나 커밋한 사람이 아닌 푸시를 실행한 사람의 계정이 표시됩니다. 그러나 배포 키와 함께 SSH 인증을 사용하여 변경 내용이 리포지토리로 푸시되는 경우 “푸시한 사람” 필드는 배포 키를 리포지토리에 추가할 때 확인한 리포지토리 관리자가 됩니다.

### 특정 분기에 푸시가 발생하는 경우에만 워크플로 실행

`branches` 또는 `branches-ignore` 필터를 사용하여 특정 분기가 푸시될 때만 실행되도록 워크플로를 구성할 수 있습니다. 자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/reference/workflows-and-actions/workflow-syntax#onpushbranchestagsbranches-ignoretags-ignore)을(를) 참조하세요.

예를 들어 이 워크플로는 다른 사용자가 `main` 분기로 푸시하거나 `releases/`로 시작하는 분기로 푸시할 때 실행됩니다.

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

> \[!NOTE]
> `branches` 필터와 `paths` 필터를 둘 다 사용하는 경우 두 필터가 모두 충족될 때만 워크플로가 실행됩니다.예를 들어 다음 워크플로는 이름이 로 시작하는 분기로 JavaScript(`.js`) 파일을 변경하는 푸시가 수행되는 경우에만 실행됩니다.`releases/`
>
> ```yaml
> on:
>   push:
>     branches:
>       - 'releases/**'
>     paths:
>       - '**.js'
> ```

### 특정 태그의 푸시가 발생하는 경우에만 워크플로 실행

`tags` 또는 `tags-ignore` 필터를 사용하여 특정 태그가 푸시될 때만 실행되도록 워크플로를 구성할 수 있습니다. 자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/reference/workflows-and-actions/workflow-syntax#onpushbranchestagsbranches-ignoretags-ignore)을(를) 참조하세요.

예를 들어 이 워크플로는 `v1.`으로 시작하는 태그를 푸시할 때 실행됩니다.

```yaml
on:
  push:
    tags:
      - v1.**
```

### 푸시가 특정 파일에 영향을 미치는 경우에만 워크플로 실행

`paths` 또는 `paths-ignore` 필터를 사용하여 특정 파일에 푸시가 발생할 때 실행되도록 워크플로를 구성할 수 있습니다. 자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore)을(를) 참조하세요.

예를 들어 이 워크플로는 JavaScript 파일(`.js`)에 변경 내용을 푸시할 때 실행됩니다.

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

## `registry_package`

| 웹후크 이벤트 페이로드                                                           | 활동 유형                         | `GITHUB_SHA` | `GITHUB_REF`      |
| ---------------------------------------------------------------------- | ----------------------------- | ------------ | ----------------- |
| [`registry_package`](/ko/webhooks/webhook-events-and-payloads#package) | - `published`<br/>- `updated` | 게시된 패키지 커밋   | 게시된 패키지의 분기 또는 태그 |

> \[!NOTE]
> \*
> 둘 이상의 활동 유형이 이 이벤트를 트리거합니다. 각 활동 유형에 대한 자세한 내용은 [웹후크 이벤트 및 페이로드](/ko/webhooks/webhook-events-and-payloads#registry_package)을 참조하세요. 기본적으로 모든 활동 유형은 이 이벤트에서 실행되는 워크플로를 트리거합니다.
> `types` 키워드를 사용하여 워크플로 실행을 특정 활동 유형으로 제한할 수 있습니다. 자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)을(를) 참조하세요.
>
> * 이 이벤트는 워크플로 파일이 기본 분기에 있는 경우에만 워크플로 실행을 트리거합니다.
> * 다중 아키텍처 컨테이너 이미지를 푸시할 경우, 해당 이벤트는 매니페스트당 한 번 발생합니다. 따라서 워크플로가 여러 번 트리거되는 것을 확인할 수 있습니다. 이 문제를 완화하기 위해, 실제 이미지 태그 정보가 포함된 이벤트에 대해서만 워크플로우 작업을 실행하도록 조건을 설정하세요.
>
> ```yaml
> jobs:
>     job_name:
>         if: $true
> ```

리포지토리에서 관련 GitHub Packages 활동이 발생할 때 워크플로를 실행합니다. 자세한 내용은 [설명서를 참조GitHub Packages하세요](/ko/packages).

예를 들어 새 패키지 버전이 `published`인 경우 워크플로를 실행할 수 있습니다.

```yaml
on:
  registry_package:
    types: [published]
```

## `release`

| 웹후크 이벤트 페이로드                                                  | 활동 유형                                                                                                                       | `GITHUB_SHA`        | `GITHUB_REF`                      |
| ------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | ------------------- | --------------------------------- |
| [`release`](/ko/webhooks/webhook-events-and-payloads#release) | - `published` <br/>- `unpublished` <br/>- `created` <br/>- `edited` <br/>- `deleted` <br/>- `prereleased`<br/> - `released` | 태그가 지정된 릴리스의 마지막 커밋 | 릴리스의 태그 참조 `refs/tags/<tag_name>` |

> \[!NOTE]
> \*
> 둘 이상의 활동 유형이 이 이벤트를 트리거합니다. 각 활동 유형에 대한 자세한 내용은 [웹후크 이벤트 및 페이로드](/ko/webhooks/webhook-events-and-payloads#release)을 참조하세요. 기본적으로 모든 활동 유형은 이 이벤트에서 실행되는 워크플로를 트리거합니다.
> `types` 키워드를 사용하여 워크플로 실행을 특정 활동 유형으로 제한할 수 있습니다. 자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)을(를) 참조하세요.
>
> * 워크플로는 초안 릴리스 `created`, `edited`, 또는 `deleted` 작업 유형에 대해서는 트리거되지 않습니다.
>   GitHub UI를 통해 릴리스를 만들면 릴리스가 자동으로 초안으로 저장될 수 있습니다.
> *

`prereleased` 유형은 초안 릴리스로 게시된 시험판에서는 트리거되지 않으나 `published` 유형은 트리거됩니다. 안정적인 사전 릴리스가 게시될 때 워크플로를 실행하려면 \_\_ 와 `published` 대신 `released`를 구독합니다.`prereleased`

리포지토리에서 릴리스 작업이 발생하면 워크플로를 실행합니다. 릴리즈 API에 대한 자세한 내용은 GraphQL API 설명서의 [릴리스](/ko/graphql/reference/releases#object-release) 또는 REST API 설명서의 [릴리스 및 릴리스 자산에 대한 REST API 엔드포인트](/ko/rest/releases)을(를) 참조하세요.

예를 들어 릴리스가 `published`된 경우 워크플로를 실행할 수 있습니다.

```yaml
on:
  release:
    types: [published]
```

## `repository_dispatch`

| 웹후크 이벤트 페이로드                                                                         | 활동 유형  | `GITHUB_SHA`  | `GITHUB_REF` |
| ------------------------------------------------------------------------------------ | ------ | ------------- | ------------ |
| [repository\_dispatch](/ko/webhooks/webhook-events-and-payloads#repository_dispatch) | 사용자 지정 | 기본 분기의 마지막 커밋 | 기본 분기        |

> \[!NOTE]
> 이 이벤트는 워크플로 파일이 기본 분기에 있는 경우에만 워크플로 실행을 트리거합니다.

API를 GitHub 사용하여 `repository_dispatch` 외부에서 발생하는 활동에 대한 워크플로를 트리거하려는 경우, [](/ko/webhooks/webhook-events-and-payloads#repository_dispatch)라는 웹후크 이벤트를 호출하여 트리거할 수 있습니다. 자세한 내용은 [리포지토리에 대한 REST API 엔드포인트](/ko/rest/repos/repos#create-a-repository-dispatch-event)을(를) 참조하세요.

`repository_dispatch` 이벤트 만들기를 요청할 때 작업 유형을 설명하는 `event_type`을 지정해야 합니다. 기본적으로 모든 `repository_dispatch` 유형의 작업은 워크플로를 실행하도록 트리거합니다.
`types` 키워드를 사용하여 `event_type` 웹후크 페이로드에서 특정 `repository_dispatch` 값을 보낼 때 워크플로를 실행하도록 제한할 수 있습니다.

```yaml
on:
  repository_dispatch:
    types: [test_result]
```

> \[!NOTE]
> `event_type` 값은 최대 100자까지 입력할 수 있습니다.

`client_payload` 매개 변수를 통해 보내는 모든 데이터는 워크플로의 `github.event` 컨텍스트에서 사용할 수 있습니다. 예를 들어 리포지토리 디스패치 이벤트를 만들 때 다음과 같은 요청 본문을 보내는 경우

```json
{
  "event_type": "test_result",
  "client_payload": {
    "passed": false,
    "message": "Error: timeout"
  }
}
```

다음과 같은 워크플로의 페이로드에 액세스할 수 있습니다.

```yaml
on:
  repository_dispatch:
    types: [test_result]

jobs:
  run_if_failure:
    if: ${{ !github.event.client_payload.passed }}
    runs-on: ubuntu-latest
    steps:
      - env:
          MESSAGE: ${{ github.event.client_payload.message }}
        run: echo $MESSAGE
```

> \[!NOTE]
> \*
> `client_payload`의 최상위 속성은 최대 10개까지 지정할 수 있습니다.
>
> * 페이로드의 최대 문자 수는 65,535자입니다.

## `schedule`

| 웹후크 이벤트 페이로드 | 활동 유형 | `GITHUB_SHA`  | `GITHUB_REF` |
| ------------ | ----- | ------------- | ------------ |
| 해당 없음        | 해당 없음 | 기본 분기의 마지막 커밋 | 기본 분기        |

> \[!NOTE]
>
> * GitHub Actions 워크플로가 실행되는 로드가 많은 기간 동안 `schedule` 이벤트가 지연될 수 있습니다. 높은 로드 시간에는 매 시간의 시작이 포함됩니다. 부하가 높으면 대기 중인 작업 일부가 삭제될 수 있습니다. 지연 가능성을 줄이려면 워크플로가 다른 시간에 실행되도록 예약합니다.
> * 이 이벤트는 워크플로 파일이 기본 분기에 있는 경우에만 워크플로 실행을 트리거합니다.
> * 예약된 워크플로는 기본 분기에서만 실행되도록 설정되어 있습니다.
> * 퍼블릭 리포지토리에서 예약된 워크플로는 60일 동안 리포지토리 작업이 발생하지 않은 경우 자동으로 사용할 수 없게 됩니다. 사용이 중단된 워크플로를 재개하는 방법에 대한 자세한 내용은 [워크플로를 사용/사용하지 않도록 설정](/ko/actions/how-tos/manage-workflow-runs/disable-and-enable-workflows#enabling-a-workflow)을 참고하세요.

`schedule` 이벤트를 사용하면 예약된 시간에 워크플로를 트리거할 수 있습니다.

**Example:**

```yaml
 on:
   schedule:
     - cron: "15 4,5 * * *"
```

[POSIX cron 구문을](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html#tag_20_25_07) 사용하여 특정 시간에 실행되도록 워크플로를 예약합니다. 기본적으로 예약된 워크플로는 UTC로 실행됩니다. 필요에 따라 표준 시간대 인식 일정에 [IANA 표준 시간대 문자열](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones) 을 사용하여 표준 시간대를 지정할 수 있습니다. 예약된 워크플로는 기본 분기의 최신 커밋에서 실행됩니다. 예약된 워크플로를 실행할 수 있는 가장 짧은 간격은 5분마다 한 번입니다.

> \[!NOTE]
> DST(일광 절약 시간제)를 관찰하는 표준 시간대로 설정된 `timezone` 일정의 경우 DST 스프링 포워드 전환 중에 건너뛴 시간에 예약된 워크플로가 다음 유효한 시간으로 진행됩니다. 예를 들어 오전 2시 30분 일정은 오전 3:00까지 진행됩니다.

Cron 구문에는 공백으로 구분된 5개의 필드가 있으며 각 필드는 시간 단위를 나타냅니다.

```text
┌───────────── minute (0 - 59)
│ ┌───────────── hour (0 - 23)
│ │ ┌───────────── day of the month (1 - 31)
│ │ │ ┌───────────── month (1 - 12 or JAN-DEC)
│ │ │ │ ┌───────────── day of the week (0 - 6 or SUN-SAT)
│ │ │ │ │
* * * * *
```

5개 필드 모두에서 다음과 같은 연산자를 사용할 수 있습니다.

| 운영자                                                   | 설명         | 예시                                                            |
| ----------------------------------------------------- | ---------- | ------------------------------------------------------------- |
| \*                                                    | 모든 값       |                                                               |
| `15 * * * *`의 경우 매일 매시 15분마다 실행됩니다.                   |            |                                                               |
| =                                                     | 값 목록 구분 기호 |                                                               |
| `2,10 4,5 * * *`의 경우 매일 4번째 및 5번째 시간의 2분과 10분에 실행됩니다. |            |                                                               |
| -                                                     | 값의 범위      |                                                               |
| `30 4-6 * * *`의 경우 4번째, 5번째 및 6번째 시간의 30분에 실행됩니다.     |            |                                                               |
| /                                                     | 단계 값       | 20분부터 59분까지 매 15분마다(`20/15 * * * *`는 20, 35, 그리고 50분에) 실행됩니다. |

이 예제에서는 매주 월요일부터 금요일까지 미국/New\_York 표준 시간대에서 오전 5시 30분에 실행되도록 워크플로를 트리거합니다.

```yaml
on:
  schedule:
    - cron: '30 5 * * 1-5'
      timezone: "America/New_York"
```

단일 워크플로는 여러 `schedule` 이벤트에 의해 트리거될 수 있습니다.
`schedule` 컨텍스트를 통해 워크플로를 트리거한 `github.event.schedule` 이벤트에 액세스할 수 있습니다. 이 예제에서는 매주 월\~목요일 5:30(UTC), 화요일과 목요일에는 17:30(UTC)에 실행되도록 워크플로를 트리거하지만 월요일과 수요일에는 `Not on Monday or Wednesday` 단계를 건너뜁니다.

```yaml
on:
  schedule:
    - cron: '30 5 * * 1,3'
    - cron: '30 5,17 * * 2,4'

jobs:
  test_schedule:
    runs-on: ubuntu-latest
    steps:
      - name: Not on Monday or Wednesday
        if: github.event.schedule != '30 5 * * 1,3'
        run: echo "This step will be skipped on Monday and Wednesday"
      - name: Every time
        run: echo "This step will always run"
```

> \[!NOTE]
> GitHub Actions는 비표준 구문`@yearly`, , `@monthly`, `@weekly``@daily``@hourly`및 `@reboot`를 지원하지 않습니다.

[crontab guru](https://crontab.guru/)를 사용하여 cron 구문을 생성하고 실행 시간을 확인할 수 있습니다. 시작하는 데 도움이 되는 [crontab guru 예제](https://crontab.guru/examples.html) 목록도 있습니다.

### 예약된 워크플로의 `actor`

특정 리포지토리 이벤트는 워크플로와 연결된 `actor` 의 변경을 유발합니다. 예를 들어, 예약된 워크플로가 실행되는 분기를 변경하는 저장소의 기본 분기를 변경하는 사용자는 예약된 워크플로에 대해 `actor` 가 됩니다.

비활성 상태로 예약된 워크플로는 리포지토리에 대한 `write` 권한을 가진 사용자가 워크플로의 `cron` 일정을 변경하는 커밋을 실행할 경우 다시 활성화되며, 해당 사용자는 모든 워크플로 실행과 관련된 `actor` 가 됩니다.

예약된 워크플로에 대한 알림은 워크플로 파일에서 cron 구문을 마지막으로 수정한 사용자에게 전송됩니다. 자세한 내용은 [워크플로 실행에 대한 알림](/ko/actions/concepts/workflows-and-actions/notifications-for-workflow-runs)을(를) 참조하세요.

> \[!NOTE]
> 예약된 워크플로를 트리거하는 엔터프라이즈 Enterprise Managed Users의 경우 워크플로와 연결된 사용자 계정의 `actor` 상태가 현재 활성 상태(즉, 일시 중단되거나 삭제되지 않음)가 필요합니다.
>
> * 예약된 워크플로는 해당 워크플로와 연결된 마지막 `actor`이 Enterprise Managed User ID 공급자(IdP)에 의해 프로비저닝이 해제된 경우 실행되지 않습니다. 그러나 IdP에서 마지막 `actor`Enterprise Managed User의 프로비전을 해제하지 않고 엔터프라이즈의 지정된 조직에서 멤버로만 제거된 경우, 예약된 워크플로는 해당 사용자가 `actor`로 설정된 상태로 계속 실행됩니다.
> * 마찬가지로, Enterprise Managed Users가 없는 엔터프라이즈의 경우, 조직에서 사용자를 제거해도 해당 사용자가 `actor`인 예약된 워크플로의 실행은 중단되지 않습니다.
> * 따라서 *사용자 계정의* 상태가 Enterprise Managed User 및 비-Enterprise Managed User 시나리오에서 중요한 것이며, 예약된 워크플로가 있는 조직 내에서 사용자의 \_멤버십 상태\_가 *아닙니다*.

## `status`

| 웹후크 이벤트 페이로드                                                | 활동 유형 | `GITHUB_SHA`  | `GITHUB_REF` |
| ----------------------------------------------------------- | ----- | ------------- | ------------ |
| [`status`](/ko/webhooks/webhook-events-and-payloads#status) | 해당 없음 | 기본 분기의 마지막 커밋 | 기본 분기        |

> \[!NOTE]
> 이 이벤트는 워크플로 파일이 기본 분기에 있는 경우에만 워크플로 실행을 트리거합니다.

Git 커밋의 상태가 변경되면 워크플로를 실행합니다. 예를 들어 커밋을 `error`, `failure`, `pending` 또는 `success`로 표시할 수 있습니다. 상태 변경에 대한 자세한 정보를 제공하려면 [`check_run`](#check_run) 이벤트를 사용하면 됩니다. 커밋 상태 API에 대한 자세한 내용은 GraphQL API 설명서의 [커밋](/ko/graphql/reference/commits#object-status) 또는 [커밋에 대한 REST API 엔드포인트](/ko/rest/commits#commit-statuses)을(를) 참조하세요.

예를 들어 `status` 이벤트가 발생할 때 워크플로를 실행할 수 있습니다.

```yaml
on:
  status
```

새 커밋 상태에 따라 워크플로에서 작업을 실행하려는 경우 `github.event.state` 컨텍스트를 사용할 수 있습니다. 예를 들어 다음 워크플로는 커밋 상태가 변경되면 트리거되지만 새 커밋 상태가 `if_error_or_failure` 또는 `error`인 경우에만 `failure` 작업이 실행됩니다.

```yaml
on:
  status
jobs:
  if_error_or_failure:
    runs-on: ubuntu-latest
    if: >-
      github.event.state == 'error' ||
      github.event.state == 'failure'
    steps:
      - env:
          DESCRIPTION: ${{ github.event.description }}
        run: |
          echo The status is error or failed: $DESCRIPTION
```

## `watch`

| 웹후크 이벤트 페이로드                                              | 활동 유형       | `GITHUB_SHA`  | `GITHUB_REF` |
| --------------------------------------------------------- | ----------- | ------------- | ------------ |
| [`watch`](/ko/webhooks/webhook-events-and-payloads#watch) | - `started` | 기본 분기의 마지막 커밋 | 기본 분기        |

> \[!NOTE]
> \*
> 둘 이상의 활동 유형이 이 이벤트를 트리거합니다. 활동 유형만 `started` 지원되지만 나중에 더 많은 활동 유형이 추가될 경우 활동 유형을 지정하면 워크플로가 구체적으로 유지됩니다. 각 활동 유형에 대한 자세한 내용은 [웹후크 이벤트 및 페이로드](/ko/webhooks/webhook-events-and-payloads#watch)을(를) 참조하세요. 기본적으로 모든 활동 유형은 이 이벤트에서 실행되는 워크플로를 트리거합니다.
> `types` 키워드를 사용하여 워크플로 실행을 특정 활동 유형으로 제한할 수 있습니다. 자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)을(를) 참조하세요.
>
> * 이 이벤트는 워크플로 파일이 기본 분기에 있는 경우에만 워크플로 실행을 트리거합니다.

워크플로의 리포지토리가 별표로 표시되면 워크플로를 실행합니다. 풀 리퀘스트 API에 대한 자세한 내용은 GraphQL API 설명서의 [Activity](/ko/graphql/reference/activity#mutation-addstar) 또는 [별표 표시에 대한 REST API 엔드포인트](/ko/rest/activity/starring)을(를) 참조하세요.

예를 들어 누군가가 조사식 이벤트의 `started` 작업 유형인 리포지토리에 별을 표시할 때 워크플로를 실행할 수 있습니다.

```yaml
on:
  watch:
    types: [started]
```

## `workflow_call`

| 웹후크 이벤트 페이로드 | 활동 유형 | `GITHUB_SHA` | `GITHUB_REF` |
| ------------ | ----- | ------------ | ------------ |
| 호출자 워크플로와 동일 | 해당 없음 | 호출자 워크플로와 동일 | 호출자 워크플로와 동일 |

`workflow_call`은 워크플로가 다른 워크플로 내에서 호출될 수 있음을 나타내는 데 사용됩니다. 워크플로가 `workflow_call` 이벤트로 트리거되면 호출된 워크플로의 이벤트 페이로드는 호출 워크플로의 이벤트 페이로드와 동일합니다. 자세한 내용은 [워크플로 재사용](/ko/actions/how-tos/reuse-automations/reuse-workflows)을(를) 참조하세요.

아래 예제에서는 워크플로가 다른 워크플로에서 호출된 경우에만 실행됩니다.

```yaml
on: workflow_call
```

## `workflow_dispatch`

| 웹후크 이벤트 페이로드                                                                     | 활동 유형             | `GITHUB_SHA` | `GITHUB_REF` |
| -------------------------------------------------------------------------------- | ----------------- | ------------ | ------------ |
| [workflow\_dispatch](/ko/webhooks/webhook-events-and-payloads#workflow_dispatch) | 해당 없음             |              |              |
| `GITHUB_REF` 분기 또는 태그의 마지막 커밋                                                    | 디스패치를 받은 분기 또는 태그 |              |              |

> \[!NOTE]
> 이 이벤트는 워크플로 파일이 기본 분기에 있는 경우에만 워크플로 실행을 트리거합니다.

워크플로가 수동으로 트리거되도록 하려면 `workflow_dispatch` 이벤트를 구성해야 합니다. API GitHub, GitHub CLI, 또는 UI GitHub를 사용하여 워크플로 실행을 수동으로 트리거할 수 있습니다. 자세한 내용은 [수동으로 워크플로 실행](/ko/actions/how-tos/manage-workflow-runs/manually-run-a-workflow)을(를) 참조하세요.

```yaml
on: workflow_dispatch
```

### 입력 제공

워크플로에서 직접 이벤트에 대한 사용자 지정 정의 입력 속성, 기본 입력 값 및 필수 입력을 구성할 수 있습니다. 이벤트를 트리거할 때 `ref` 및 모든 `inputs`를 제공할 수 있습니다. 워크플로가 실행되면 `inputs` 컨텍스트의 입력 값에 액세스할 수 있습니다. 자세한 내용은 [문맥 참조](/ko/actions/reference/workflows-and-actions/contexts)을(를) 참조하세요.

> \[!NOTE]
>
> * 워크플로는 `github.event.inputs` 컨텍스트의 입력도 수신합니다.
>   `inputs` 컨텍스트와 `github.event.inputs` 컨텍스트의 정보는 `inputs` 컨텍스트가 부울 값을 문자열로 변환하는 대신 부울 값으로 유지한다는 점을 제외하고 동일합니다. 이 `choice` 형식은 문자열로 확인되며 단일 선택 가능한 옵션입니다.
> * 최상위 속성 `inputs` 의 최대 수는 25 입니다.
> * 최대 페이로드 `inputs`는 65,535자입니다.

이 예에서는 `logLevel`, `tags`, 및 `environment`이라는 입력을 정의합니다. 워크플로를 실행할 때 입력에 대한 값을 워크플로에 전달합니다. 그런 다음, 이 워크플로는 `inputs.logLevel`, `inputs.tags`, `inputs.environment` 컨텍스트 속성을 사용하여 로그에 값을 출력합니다.

```yaml
on:
  workflow_dispatch:
    inputs:
      logLevel:
        description: 'Log level'
        required: true
        default: 'warning'
        type: choice
        options:
        - info
        - warning
        - debug
      tags:
        description: 'Test scenario tags'
        required: false
        type: boolean
      environment:
        description: 'Environment to run tests against'
        type: environment
        required: true

jobs:
  log-the-inputs:
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo "Log level: $LEVEL"
          echo "Tags: $TAGS"
          echo "Environment: $ENVIRONMENT"
        env:
          LEVEL: ${{ inputs.logLevel }}
          TAGS: ${{ inputs.tags }}
          ENVIRONMENT: ${{ inputs.environment }}
```

브라우저에서 이 워크플로를 실행하는 경우 워크플로가 실행되기 전에 필수 입력에 대한 값을 수동으로 입력해야 합니다.

![워크플로 실행 목록의 스크린샷입니다. 진한 주황색 테두리로 강조 표시된 ‘워크플로우 실행’ 레이블이 붙은 확장된 드롭다운 메뉴는 입력 필드를 표시합니다.](/assets/images/help/actions/workflow-dispatch-inputs.png)

스크립트에서 워크플로를 실행하거나 을 사용하여 입력을 전달할 수도 있습니다 GitHub CLI. 예를 들어:

```shell
gh workflow run run-tests.yml -f logLevel=warning -f tags=false -f environment=staging
```

자세한 내용은 GitHub CLI의 [](/ko/actions/how-tos/manage-workflow-runs/manually-run-a-workflow) 정보를 참조하세요.

## `workflow_run`

| 웹후크 이벤트 페이로드                                                            | 활동 유형                                               | `GITHUB_SHA`  | `GITHUB_REF` |
| ----------------------------------------------------------------------- | --------------------------------------------------- | ------------- | ------------ |
| [`workflow_run`](/ko/webhooks/webhook-events-and-payloads#workflow_run) | - `completed`<br/>- `requested`<br/>- `in_progress` | 기본 분기의 마지막 커밋 | 기본 분기        |

> \[!NOTE]
> \*
> 둘 이상의 활동 유형이 이 이벤트를 트리거합니다.
> `requested` 워크플로를 다시 실행할 때 활동 유형이 발생하지 않습니다. 각 활동 유형에 대한 자세한 내용은 [웹후크 이벤트 및 페이로드](/ko/webhooks/webhook-events-and-payloads#workflow_run)을(를) 참조하세요. 기본적으로 모든 활동 유형은 이 이벤트에서 실행되는 워크플로를 트리거합니다.
> `types` 키워드를 사용하여 워크플로 실행을 특정 활동 유형으로 제한할 수 있습니다. 자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/reference/workflows-and-actions/workflow-syntax#onevent_nametypes)을(를) 참조하세요.
>
> * 이 이벤트는 워크플로 파일이 기본 분기에 있는 경우에만 워크플로 실행을 트리거합니다.
> *

`workflow_run` 를 사용해서는 워크플로 수준을 세 개 이상 연결할 수 없습니다. 예를 들어 초기 워크플로 `B`가 실행된 후 순차적으로 실행되도록 (`F`부터 `A`까지의) 5개의 워크플로를 트리거하려고 하면(즉, `A` → `B` → `C` → `D` → `E` → `F`) `E` 및 `F` 워크플로가 실행되지 않습니다.

이 이벤트는 워크플로 실행을 요청하거나 완료할 때 발생합니다. 이를 통해 다른 워크플로의 실행 또는 완료에 따라 워크플로를 실행할 수 있습니다.
`workflow_run` 이벤트에 의해 시작된 워크플로는 이전 워크플로는 그렇지 않더라도 비밀에 액세스하고 토큰을 쓸 수 있습니다. 이는 이전 워크플로가 의도적으로 권한이 없지만 이후 워크플로에서 권한 있는 작업을 수행해야 하는 경우에 유용합니다.

> \[!WARNING]
> `workflow_run` 트리거에서 신뢰할 수 없는 코드를 실행하면 보안 취약성이 발생할 수 있습니다. 이러한 취약성에는 캐시 악용 및 쓰기 권한 또는 비밀에 대한 의도하지 않은 액세스 권한 부여가 포함됩니다. 자세한 내용은 GitHub Enterprise Cloud 문서의 [안전 사용 참조](/ko/enterprise-cloud@latest/actions/reference/security/secure-use#mitigating-the-risks-of-untrusted-code-checkout) 및 GitHub Security Lab 웹 사이트의 [pwn 요청 방지](https://securitylab.github.com/research/github-actions-preventing-pwn-requests)를 참조하세요.

이 예시에서는 별도의 “테스트 실행” 워크플로가 완료된 후 실행되도록 워크플로가 구성됩니다.

```yaml
on:
  workflow_run:
    workflows: [Run Tests]
    types:
      - completed
```

`workflows` 이벤트에 대해 여러 개의 `workflow_run`를 지정하는 경우 워크플로 중 하나만 실행해야 합니다. 예를 들어 다음 트리거가 있는 워크플로는 “스테이징” 워크플로 또는 “랩” 워크플로가 완료될 때마다 실행됩니다.

```yaml
on:
  workflow_run:
    workflows: [Staging, Lab]
    types:
      - completed
```

### 다른 워크플로의 결론에 따라 워크플로 실행

워크플로 실행은 이전 워크플로의 결론에 관계없이 트리거됩니다. 트리거 워크플로의 결과에 따라 작업 또는 단계를 실행하려는 경우 `github.event.workflow_run.conclusion` 속성과 함께 조건을 사용할 수 있습니다. 예를 들어 이 워크플로는 “빌드”라는 워크플로가 완료될 때마다 실행되지만, “빌드” 워크플로가 성공한 경우에만 `on-success` 작업이 실행되고 “빌드” 워크플로가 실패한 경우에만 `on-failure` 작업이 실행됩니다.

```yaml
on:
  workflow_run:
    workflows: [Build]
    types: [completed]

jobs:
  on-success:
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    steps:
      - run: echo 'The triggering workflow passed'
  on-failure:
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'failure' }}
    steps:
      - run: echo 'The triggering workflow failed'
```

### 분기를 기반으로 실행하도록 워크플로 제한

`branches` 또는 `branches-ignore` 필터를 사용하여 워크플로를 트리거하기 위해 트리거 워크플로가 실행되어야 하는 분기를 지정할 수 있습니다. 자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/reference/workflows-and-actions/workflow-syntax#onworkflow_runbranchesbranches-ignore)을(를) 참조하세요. 예를 들어 다음 트리거가 있는 워크플로는 이름이 `Build`인 분기에서 `canary`라는 워크플로가 실행되는 경우에만 실행됩니다.

```yaml
on:
  workflow_run:
    workflows: [Build]
    types: [requested]
    branches: [canary]
```

### 트리거 워크플로의 데이터 사용

워크플로를 트리거한 워크플로와 관련된 [`workflow_run`이벤트 페이로드](/ko/webhooks/webhook-events-and-payloads#workflow_run) 에 액세스할 수 있습니다. 예를 들어 트리거 워크플로에서 아티팩트가 생성되면 `workflow_run` 이벤트로 트리거된 워크플로가 아티팩트에 액세스할 수 있습니다.

다음 워크플로는 데이터를 아티팩트로 업로드합니다. (이 기본 예제에서 데이터는 끌어오기 요청 번호입니다.)

```yaml
name: Upload data

on:
  pull_request:

jobs:
  upload:
    runs-on: ubuntu-latest

    steps:
      - name: Save PR number
        env:
          PR_NUMBER: ${{ github.event.number }}
        run: |
          mkdir -p ./pr
          echo $PR_NUMBER > ./pr/pr_number
      - uses: actions/upload-artifact@v4
        with:
          name: pr_number
          path: pr/
```

위의 워크플로 실행이 완료되면 다음 워크플로의 실행을 트리거합니다. 다음 워크플로는 `github.event.workflow_run` 컨텍스트와 actions/download-artifact\@v5 작업을 사용하여 위 워크플로에서 업로드된 아티팩트를 다운로드한 다음, 번호가 아티팩트로 업로드된 풀 요청에 댓글을 답니다.

```yaml
name: Use the data

on:
  workflow_run:
    workflows: [Upload data]
    types:
      - completed

jobs:
  download:
    runs-on: ubuntu-latest
    steps:
      - name: 'Download artifact'
        uses: actions/download-artifact@v5
        with:
          name: pr_number
          # do not extract in the workspace dir that may contain executable scripts
          path: ${{ runner.temp }}/artifacts
          run-id: ${{ github.event.workflow_run.id }}
          github-token: ${{ secrets.GITHUB_TOKEN }}

      - name: 'Comment on PR'
        uses: actions/github-script@v8
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            const fs = require('fs');
            const path = require('path');
            const temp = '${{ runner.temp }}/artifacts';
            const issue_number_raw = fs.readFileSync(path.join(temp, 'pr_number'), 'utf8').trim();
            const issue_number = Number(issue_number_raw);
            if (!Number.isInteger(issue_number)) {
              throw new Error(`Invalid PR number in pr_number artifact: "${issue_number_raw}"`);
            }
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: issue_number,
              body: 'Thank you for the PR!'
            });
```