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

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

워크플로 트리거는 워크플로를 실행하게 하는 이벤트입니다. 워크플로 트리거를 사용하는 방법에 대한 자세한 내용은 "워크플로 트리거"을 참조하세요.

일부 이벤트에는 여러 작업 유형이 있습니다. 해당 이벤트의 경우 워크플로 실행을 트리거할 작업 유형을 지정할 수 있습니다. 각 활동 유형의 의미에 대한 자세한 내용은 "웹후크 이벤트 및 페이로드"을 참조하세요.

branch_protection_rule

워크플로 리포지토리의 분기 보호 규칙이 변경되면 워크플로를 실행합니다. 브랜치 보호 규칙에 대한 자세한 내용은 "보호된 분기 정보"을 참조하세요. 브랜치 보호 규칙 API에 대한 자세한 내용은 GraphQL API 설명서의 "개체" 또는 "분기 및 해당 설정에 대한 REST API 엔드포인트" 항목을 참조하세요.

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

on:
  branch_protection_rule:
    types: [created, deleted]

check_run

검사 실행과 관련된 작업이 발생할 때 워크플로를 실행합니다. 검사 실행은 검사 도구 모음의 일부인 개별 테스트입니다. 자세한 내용은 "REST API를 사용하여 검사 상호 작용"을 참조하세요. 검사 실행 API에 대한 자세한 내용은 GraphQL API 설명서의 "개체" 또는 "검사 실행에 대한 REST API 엔드포인트" 항목을 참조하세요.

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

on:
  check_run:
    types: [rerequested, completed]

check_suite

검사 도구 모음 작업이 발생할 때 워크플로를 실행합니다. 검사 도구 모음은 특정 커밋에 대해 생성된 검사 실행의 컬렉션입니다. 검사 도구 모음은 도구 모음에 있는 검사 실행의 상태와 결론을 요약합니다. 자세한 내용은 "REST API를 사용하여 검사 상호 작용"을 참조하세요. 검사 제품군 API에 대한 자세한 내용은 GraphQL API 설명서의 "개체" 또는 "검사 도구 모음에 대한 REST API 엔드포인트" 항목을 참조하세요.

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

on:
  check_suite:
    types: [completed]

create

누군가가 워크플로의 리포지토리에서 Git 참조(Git 분기 또는 태그)를 만들 때 워크플로를 실행합니다. Git 참조를 만들기 위한 API에 대한 자세한 내용은 GraphQL API 설명서의 "변형" 또는 "Git 참조에 대한 REST API 엔드포인트" 항목을 참조하세요.

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

on:
  create

delete

누군가가 워크플로의 리포지토리에서 Git 참조(Git 분기 또는 태그)를 삭제할 때 워크플로를 실행합니다. Git 참조를 삭제하는 API에 대한 자세한 내용은 GraphQL API 설명서의 "변형" 또는 "Git 참조에 대한 REST API 엔드포인트" 항목을 참조하세요.

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

on:
  delete

deployment

누군가가 워크플로의 리포지토리에서 배포를 만들 때 워크플로를 실행합니다. 커밋 SHA로 생성된 배포에는 Git 참조가 없을 수 있습니다. 배포를 생성하기 위한 API에 대한 자세한 내용은 GraphQL API 설명서의 "변형" 또는 "리포지토리에 대한 REST API 엔드포인트"을 참조하세요.

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

on:
  deployment

deployment_status

타사에서 배포 상태를 제공하는 경우 워크플로를 실행합니다. 커밋 SHA로 생성된 배포에는 Git 참조가 없을 수 있습니다. 배포 상태를 생성하기 위한 API에 대한 자세한 내용은 GraphQL API 설명서의 "변형" 또는 "배포에 대한 REST API 엔드포인트" 항목을 참조하세요.

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

on:
  deployment_status

discussion

워크플로의 리포지토리에서 토론이 만들어지거나 수정될 때 워크플로를 실행합니다. 토론의 댓글과 관련된 작업의 경우 discussion_comment 이벤트를 사용합니다. 토론에 대한 자세한 내용은 "토론 정보"을 참조하세요. GraphQL API에 대한 자세한 내용은 "개체"을 참조하십시오.

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

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

discussion_comment

워크플로의 리포지토리에서 토론의 댓글이 만들어지거나 수정될 때 워크플로를 실행합니다. 토론 댓글이 아닌 토론 관련 작업의 경우 discussion 이벤트를 사용합니다. 토론에 대한 자세한 내용은 "토론 정보"을 참조하세요. GraphQL API에 대한 자세한 내용은 "개체"을 참조하십시오.

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

on:
  discussion_comment:
    types: [created, deleted]

fork

누군가가 리포지토리를 포크할 때 워크플로를 실행합니다. REST API에 대한 자세한 내용은 "포크에 대한 REST API 엔드포인트"을 참조하십시오.

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

on:
  fork

gollum

누군가가 Wiki 페이지를 만들거나 업데이트할 때 워크플로를 실행합니다. 자세한 내용은 "위키 정보"을(를) 참조하세요.

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

on:
  gollum

issue_comment

문제 또는 끌어오기 요청 설명이 생성, 편집 또는 삭제될 때 워크플로를 실행합니다. 이슈 댓글 API에 대한 자세한 내용은 GraphQL API 설명서의 "개체" 또는 REST API 설명서의 "웹후크 이벤트 및 페이로드"을 참조하세요.

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

on:
  issue_comment:
    types: [created, deleted]

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

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

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

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

워크플로의 리포지토리에서 문제가 만들어지거나 수정될 때 워크플로를 실행합니다. 문제의 설명과 관련된 작업의 경우 issue_comment 이벤트를 사용합니다. 문제에 대한 자세한 내용은 "문제 정보"을 참조하세요. 이슈 API에 대한 자세한 내용은 GraphQL API 설명서의 "개체" 또는 "이슈에 대한 REST API 엔드포인트" 항목을 참조하세요.

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

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

label

워크플로의 리포지토리에서 레이블이 만들어지거나 수정될 때 워크플로를 실행합니다. 레이블에 대한 자세한 내용은 "레이블 관리"을 참조하십시오. 레이블 API에 대한 자세한 내용은 GraphQL API 설명서의 "개체" 또는 "레이블에 대한 REST API 엔드포인트" 항목을 참조하세요.

레이블이 문제, 끌어오기 요청 또는 토론에서 추가되거나 제거될 때 워크플로를 실행하려면 issues, pull_request, pull_request_target 또는 discussion 이벤트 대신 labeled 또는 unlabeled 작업 유형을 사용합니다.

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

on:
  label:
    types: [created, deleted]

milestone

워크플로의 리포지토리에서 마일스톤이 만들어지거나 수정될 때 워크플로를 실행합니다. 마일스톤에 대한 자세한 내용은 "마일스톤 정보"을 참조하십시오. 마일스톤 API에 대한 자세한 내용은 GraphQL API 설명서의 "개체" 또는 "마일스톤에 대한 REST API 엔드포인트" 항목을 참조하세요.

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

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

on:
  milestone:
    types: [opened, deleted]

page_build

GitHub Pages가 리포지토리에 대해 사용하도록 설정된 경우 누군가가 GitHub Pages의 게시 원본인 분기로 푸시할 때 워크플로를 실행합니다. 데이터 변수 GitHub Pages 퍼블리싱 소스에 대한 자세한 내용은 "GitHub Pages 사이트에 대한 게시 원본 구성"을 참조하십시오. REST API에 대한 자세한 내용은 "리포지토리에 대한 REST API 엔드포인트"을 참조하십시오.

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

on:
  page_build

project

프로젝트(클래식)을(를) 생성하거나 수정할 때 워크플로를 실행합니다. 프로젝트(클래식)의 카드 또는 열과 관련된 활동의 경우 project_card 또는 project_column 이벤트를 대신 사용합니다. 프로젝트(클래식)에 대한 자세한 내용은 "projects (classic) 정보"을(를) 참조하세요. 프로젝트(클래식) API에 대한 자세한 내용은 GraphQL API 설명서의 "개체" 또는 "Projects (classic)에 대한 REST API 엔드포인트" 항목을 참조하세요.

예를 들어 프로젝트가 created 또는 deleted된 경우 워크플로를 실행할 수 있습니다.

on:
  project:
    types: [created, deleted]

project_card

프로젝트(클래식)에서 카드를 생성하거나 수정할 때 워크플로를 실행합니다. 프로젝트(클래식) 또는 프로젝트(클래식)의 열과 관련된 활동의 경우 project 또는 project_column 이벤트를 대신 사용합니다. 프로젝트(클래식)에 대한 자세한 내용은 "projects (classic) 정보"을(를) 참조하세요. 프로젝트 카드 API에 대한 자세한 내용은 GraphQL API 설명서의 "개체" 또는 "Project (classic) 카드에 대한 REST API 엔드포인트" 항목을 참조하세요.

예를 들어 프로젝트 카드가 created 또는 deleted된 경우 워크플로를 실행할 수 있습니다.

on:
  project_card:
    types: [created, deleted]

project_column

프로젝트(클래식)에서 열을 생성하거나 수정할 때 워크플로를 실행합니다. 프로젝트(클래식) 또는 프로젝트(클래식)의 카드와 관련된 활동의 경우 project 또는 project_card 이벤트를 대신 사용합니다. 프로젝트(클래식)에 대한 자세한 내용은 "projects (classic) 정보"을(를) 참조하세요. 프로젝트 열 API에 대한 자세한 내용은 GraphQL API 설명서의 "개체" 또는 "Projects (classic)에 대한 REST API 엔드포인트" 항목을 참조하세요.

예를 들어 프로젝트 열이 created 또는 deleted된 경우 워크플로를 실행할 수 있습니다.

on:
  project_column:
    types: [created, deleted]

public

워크플로의 리포지토리가 프라이빗에서 퍼블릭으로 변경되면 워크플로를 실행합니다. REST API에 대한 자세한 내용은 "리포지토리에 대한 REST API 엔드포인트"을 참조하십시오.

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

on:
  public

pull_request

워크플로 리포지토리의 끌어오기 요청에 대한 작업이 발생할 때 워크플로를 실행합니다. 예를 들어 작업 형식이 지정되지 않은 경우 끌어오기 요청이 열리거나 다시 열리거나 끌어오기 요청의 헤드 분기가 업데이트될 때 워크플로가 실행됩니다. 끌어오기 요청 검토, 끌어오기 요청 검토 주석 또는 끌어오기 요청 주석과 관련된 작업의 경우 pull_request_review, pull_request_review_comment, 또는 issue_comment 이벤트를 대신 사용합니다. 끌어오기 요청 API에 대한 자세한 내용은 GraphQL API 설명서의 "개체" 또는 "끌어오기 요청에 대한 REST API 엔드포인트" 항목을 참조하세요.

이 이벤트의 GITHUB_SHA는 끌어오기 요청 병합 분기의 마지막 병합 커밋입니다. 끌어오기 요청 헤드 분기의 마지막 커밋에 대한 커밋 ID를 가져오려면 github.event.pull_request.head.sha를 대신 사용합니다.

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

on:
  pull_request:
    types: [opened, reopened]

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

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에 대한 워크플로 구문"을(를) 참조하세요.

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

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

on:
  pull_request:
    types:
      - opened
    branches:
      - 'releases/**'
    paths:
      - '**.js'

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

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에 대한 워크플로 구문"을(를) 참조하세요.

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

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

on:
  pull_request:
    types:
      - opened
    branches:
      - 'releases/**'
    paths:
      - '**.js'

풀 리퀘스트가 병합될 때 pull_request 워크플로 실행하기

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

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 Enterprise Server는 기본 리포지토리에 pull_request, issue_comment, pull_request_review_comment, pull_request_review, pull_request_target 이벤트를 보냅니다. 포크된 리포지토리에서는 끌어오기 요청 이벤트가 발생하지 않습니다.

포크된 리포지토리에서 프라이빗 리포지토리로 끌어오기 요청은 워크플로가 활성화 상태일 때만 실행됩니다. "리포지토리에 대한 GitHub Actions 설정 관리"을 참조하세요.

pull_request_comment(issue_comment 사용)

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

pull_request_review

끌어오기 요청 검토가 제출되거나 편집되거나 해제될 때 워크플로를 실행합니다. 끌어오기 요청 검토는 본문 주석 및 상태 외에도 끌어오기 요청 검토 주석 그룹입니다. 끌어오기 요청 검토 주석 또는 끌어오기 요청 주석과 관련된 활동의 경우 pull_request_review_comment 또는 issue_comment 이벤트를 대신 사용합니다. 끌어오기 요청 검토 API에 대한 자세한 내용은 GraphQL API 설명서의 "개체" 또는 "끌어오기 요청에 대한 REST API 엔드포인트" 항목을 참조하세요.

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

on:
  pull_request_review:
    types: [edited, dismissed]

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

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

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 Enterprise Server는 기본 리포지토리에 pull_request, issue_comment, pull_request_review_comment, pull_request_review, pull_request_target 이벤트를 보냅니다. 포크된 리포지토리에서는 끌어오기 요청 이벤트가 발생하지 않습니다.

포크된 리포지토리에서 프라이빗 리포지토리로 끌어오기 요청은 워크플로가 활성화 상태일 때만 실행됩니다. "리포지토리에 대한 GitHub Actions 설정 관리"을 참조하세요.

pull_request_review_comment

끌어오기 요청 검토 주석이 수정되면 워크플로를 실행합니다. 끌어오기 요청 검토 주석은 끌어오기 요청의 diff에 대한 주석입니다. 끌어오기 요청 검토 또는 끌어오기 요청 주석과 관련된 활동의 경우 pull_request_review 또는 issue_comment 이벤트를 대신 사용합니다. 끌어오기 요청 검토 메모 API에 대한 자세한 내용은 GraphQL API 설명서의 "개체" 또는 "끌어오기 요청에 대한 REST API 엔드포인트" 항목을 참조하세요.

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

on:
  pull_request_review_comment:
    types: [created, deleted]

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

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

GITHUB_TOKEN의 예외를 제외하고 포크된 리포지토리에서 워크플로가 트리거될 때 비밀이 실행기에게 전달되지 않습니다. GITHUB_TOKEN에는 포크된 리포지토리 끌어오기 요청의 읽기 전용 권한이 있습니다. 자세한 내용은 "자동 토큰 인증"을 참조하세요.

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

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

포크된 리포지토리에서 프라이빗 리포지토리로 끌어오기 요청은 워크플로가 활성화 상태일 때만 실행됩니다. "리포지토리에 대한 GitHub Actions 설정 관리"을 참조하세요.

pull_request_target

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

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

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

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

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

풀 리퀘스트의 헤드 또는 베이스 브랜치를 기반으로 pull_request_target 워크플로 실행하기

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

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

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

on:
  pull_request_target:
    types:
      - opened
    branches:
      - 'releases/**'
    paths:
      - '**.js'

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

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에 대한 워크플로 구문"을(를) 참조하세요.

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

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

on:
  pull_request_target:
    types:
      - opened
    branches:
      - 'releases/**'
    paths:
      - '**.js'

풀 리퀘스트가 병합될 때 pull_request_target 워크플로 실행하기

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

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

커밋 또는 태그를 푸시하거나 템플릿에서 리포지토리를 만들 때 워크플로우를 실행합니다.

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

on:
  push

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

branches 또는 branches-ignore 필터를 사용하여 특정 분기가 푸시될 때만 실행되도록 워크플로를 구성할 수 있습니다. 자세한 내용은 "GitHub Actions에 대한 워크플로 구문"을(를) 참조하세요.

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

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

on:
  push:
    branches:
      - 'releases/**'
    paths:
      - '**.js'

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

tags 또는 tags-ignore 필터를 사용하여 특정 태그가 푸시될 때만 실행되도록 워크플로를 구성할 수 있습니다. 자세한 내용은 "GitHub Actions에 대한 워크플로 구문"을(를) 참조하세요.

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

on:
  push:
    tags:
      - v1.**

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

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

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

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

on:
  push:
    branches:
      - 'releases/**'
    paths:
      - '**.js'

registry_package

jobs:
    job_name:
        if: ${{ github.event.registry_package.package_version.container_metadata.tag.name != '' }}

리포지토리에서 GitHub Packages에 관련된 작업이 발생하면 워크플로를 실행합니다. 자세한 내용은 “GitHub Packages 설명서”를 참조하세요.

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

on:
  registry_package:
    types: [published]

release

리포지토리에서 릴리스 작업이 발생하면 워크플로를 실행합니다. 릴리스 API에 대한 자세한 내용은 GraphQL API 설명서의 "개체" 또는 REST API 설명서의 "릴리스 및 릴리스 자산에 대한 REST API 엔드포인트"을 참조하세요.

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

on:
  release:
    types: [published]

repository_dispatch

GitHub Enterprise Server 외부에서 발생하는 작업에 대한 워크플로를 트리거하려는 경우 GitHub Enterprise Server API를 사용하여 repository_dispatch라고 불리는 웹후크 이벤트를 트리거할 수 있습니다. 자세한 내용은 "리포지토리에 대한 REST API 엔드포인트"을(를) 참조하세요.

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

on:
  repository_dispatch:
    types: [test_result]

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

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

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

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

schedule

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

POSIX cron 구문을 사용하여 특정 UTC 시간에 워크플로를 실행하도록 예약할 수 있습니다. 예약된 워크플로는 기본 분기 또는 베이스 분기의 최신 커밋에서 실행됩니다. 예약된 워크플로를 실행할 수 있는 가장 짧은 간격은 5분마다 한 번입니다.

이 예제에서는 매일 5:30 및 17:30 UTC에 워크플로를 트리거합니다.

on:
  schedule:
    # * is a special character in YAML so you have to quote this string
    - cron:  '30 5,17 * * *'

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

on:
  schedule:
    - cron: '30 5 * * 1,3'
    - cron: '30 5 * * 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"

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

┌───────────── 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개 필드 모두에서 다음과 같은 연산자를 사용할 수 있습니다.

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

예약된 워크플로에 대한 알림은 워크플로 파일에서 cron 구문을 마지막으로 수정한 사용자에게 전송됩니다. 자세한 내용은 "워크플로 실행에 대한 알림"을(를) 참조하세요.

status

Git 커밋의 상태가 변경되면 워크플로를 실행합니다. 예를 들어 커밋을 error, failure, pending 또는 success로 표시할 수 있습니다. 상태 변경에 대한 자세한 정보를 제공하려는 경우 check_run 이벤트를 사용할 수 있습니다. 커밋 상태 API에 대한 자세한 내용은 GraphQL API 설명서의 "개체" 또는 "커밋에 대한 REST API 엔드포인트" 항목을 참조하세요.

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

on:
  status

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

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

워크플로의 리포지토리가 별표로 표시되면 워크플로를 실행합니다. 끌어오기 요청 API에 대한 자세한 내용은 GraphQL API 설명서의 "변형" 또는 "별표 표시에 대한 REST API 엔드포인트" 항목을 참조하세요.

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

on:
  watch:
    types: [started]

workflow_call

workflow_call은 다른 워크플로에서 워크플로를 호출할 수 있음을 나타내는 데 사용됩니다. 워크플로가 workflow_call 이벤트로 트리거되면 호출된 워크플로의 이벤트 페이로드는 호출 워크플로의 이벤트 페이로드와 동일합니다. 자세한 내용은 "워크플로 다시 사용"을 참조하세요.

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

on: workflow_call

workflow_dispatch

워크플로우가 수동으로 트리거되도록 하려면 workflow_dispatch 이벤트를 구성해야 합니다. GitHub Enterprise Server API, GitHub CLI 또는 GitHub Enterprise Server 브라우저 인터페이스를 사용하여 워크플로 실행을 수동으로 트리거할 수 있습니다. 자세한 내용은 "워크플로 수동 실행"을(를) 참조하세요.

on: workflow_dispatch

입력 제공

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

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

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 }}

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

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

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

자세한 내용은 "워크플로 수동 실행"의 GitHub CLI 정보를 참조하세요.

workflow_run

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

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

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

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

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

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

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

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에 대한 워크플로 구문"을(를) 참조하세요. 예를 들어 다음 트리거가 있는 워크플로는 이름이 canary인 분기에서 Build라는 워크플로가 실행되는 경우에만 실행됩니다.

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

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

워크플로를 트리거한 워크플로에 해당하는 workflow_run이벤트 페이로드에 액세스할 수 있습니다. 예를 들어 트리거 워크플로에서 아티팩트가 생성되면 workflow_run 이벤트로 트리거된 워크플로가 아티팩트에 액세스할 수 있습니다.

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

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@v3
        with:
          name: pr_number
          path: pr/

위의 워크플로 실행이 완료되면 다음 워크플로의 실행을 트리거합니다. 다음 워크플로에서는 github.event.workflow_run 컨텍스트 및 GitHub Enterprise Server REST API를 사용하여 위의 워크플로에서 업로드한 아티팩트를 다운로드하고, 다운로드한 아티팩트 압축을 풀고, 숫자가 아티팩트로 업로드된 끌어오기 요청에 대한 주석을 다운로드합니다.

name: Use the data

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

jobs:
  download:
    runs-on: ubuntu-latest
    steps:
      - name: 'Download artifact'
        uses: actions/github-script@v6
        with:
          script: |
            let allArtifacts = await github.rest.actions.listWorkflowRunArtifacts({
               owner: context.repo.owner,
               repo: context.repo.repo,
               run_id: context.payload.workflow_run.id,
            });
            let matchArtifact = allArtifacts.data.artifacts.filter((artifact) => {
              return artifact.name == "pr_number"
            })[0];
            let download = await github.rest.actions.downloadArtifact({
               owner: context.repo.owner,
               repo: context.repo.repo,
               artifact_id: matchArtifact.id,
               archive_format: 'zip',
            });
            let fs = require('fs');
            fs.writeFileSync(`${process.env.GITHUB_WORKSPACE}/pr_number.zip`, Buffer.from(download.data));

      - name: 'Unzip artifact'
        run: unzip pr_number.zip

      - name: 'Comment on PR'
        uses: actions/github-script@v6
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            let fs = require('fs');
            let issue_number = Number(fs.readFileSync('./pr_number'));
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: issue_number,
              body: 'Thank you for the PR!'
            });