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

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

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

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

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 참조가 없을 수 있습니다. 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

image_version

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

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

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

issue_comment

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

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

on:
  issue_comment:
    types: [created, deleted]

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

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

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

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 엔드포인트을(를) 참조하세요.

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

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

on:
  label:
    types: [created, deleted]

merge_group

끌어오기 요청이 병합 큐에 추가되면 워크플로를 실행합니다. 그러면 병합 그룹에 끌어오기 요청이 추가됩니다. 자세한 내용은 끌어오기 요청을 병합 대기열과 병합하기을(를) 참조하세요.

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

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

milestone

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

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

예를 들어 마일스톤이 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

public

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

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

on:
  public

pull_request

          `GITHUB_REF` 분기의 마지막 병합 커밋 | PR 병합 분기 `refs/pull/PULL_REQUEST_NUMBER/merge` |

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

• 종료된 풀 리퀘스트의 GITHUB_REF 값은 해당 풀 리퀘스트가 병합되었는지 여부에 따라 달라집니다. 병합되지 않고 풀 리퀘스트가 종료되면 refs/pull/PULL_REQUEST_NUMBER/merge이 됩니다. 병합된 결과로 풀 리퀘스트가 종료되면, 병합된 분기는 ref 와 같이 정규화됩니다. 예를 들어 /refs/heads/main 와 같습니다.

워크플로 리포지토리의 끌어오기 요청에 대한 작업이 발생할 때 워크플로를 실행합니다. 예를 들어 작업 형식이 지정되지 않은 경우 끌어오기 요청이 열리거나 다시 열리거나 끌어오기 요청의 헤드 분기가 업데이트될 때 워크플로가 실행됩니다. 끌어오기 요청 검토, 끌어오기 요청 검토 주석 또는 끌어오기 요청 주석과 관련된 작업의 경우 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` 필터를 사용하여 특정 분기를 대상으로 하는 끌어오기 요청에서만 실행되도록 워크플로를 구성할 수 있습니다. 자세한 내용은 [AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore)을(를) 참조하세요.

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

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

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

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

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 워크플로 실행

끌어오기 요청이 병합되면 끌어오기 요청이 자동으로 닫힙니다. pull_request closed 이벤트 형식을 사용하여 끌어오기 요청이 병합될 경우 워크플로가 실행되도록 설정하고, merged 이벤트 값을 확인하는 조건을 설정합니다. 예를 들어 끌어오기 요청이 닫힐 때마다 다음 워크플로가 실행됩니다. 끌어오기 요청도 병합된 경우에만 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_TOKEN 사용을(를) 참조하세요.

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

포크된 리포지토리에서 기본 리포지토리로의 끌어오기 요청의 경우 GitHub는 기본 리포지토리에 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

          `GITHUB_REF` 분기의 마지막 병합 커밋 | PR 병합 분기 `refs/pull/PULL_REQUEST_NUMBER/merge` |

끌어오기 요청 검토가 제출되거나 편집되거나 해제될 때 워크플로를 실행합니다. 끌어오기 요청 검토는 본문 주석 및 상태 외에도 끌어오기 요청 검토 주석 그룹입니다. 끌어오기 요청 검토 주석 또는 끌어오기 요청 주석과 관련된 활동의 경우 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_TOKEN 사용을(를) 참조하세요.

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

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

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

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

pull_request_review_comment

          `GITHUB_REF` 분기의 마지막 병합 커밋 | PR 병합 분기 `refs/pull/PULL_REQUEST_NUMBER/merge` |

끌어오기 요청 검토 주석이 수정되면 워크플로를 실행합니다. 끌어오기 요청 검토 주석은 끌어오기 요청의 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_TOKEN 사용을(를) 참조하세요.

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

포크된 리포지토리에서 기본 리포지토리로의 끌어오기 요청의 경우 GitHub는 기본 리포지토리에 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` 필터를 사용하여 특정 분기를 대상으로 하는 끌어오기 요청에서만 실행되도록 워크플로를 구성할 수 있습니다. 자세한 내용은 [AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore)을(를) 참조하세요.

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

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

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

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

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 워크플로 실행

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

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

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

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

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

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

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

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

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

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

on:
  push:
    tags:
      - v1.**

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

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

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

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

registry_package

jobs:
    job_name:
        if: $true

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

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

on:
  registry_package:
    types: [published]

release

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

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

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

on:
  release:
    types: [published]

repository_dispatch

          [repository_dispatch](/webhooks-and-events/webhooks/webhook-events-and-payloads#repository_dispatch) | 사용자 지정 | 기본 분기의 마지막 커밋 | 기본 분기 |

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

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

on:
  repository_dispatch:
    types: [test_result]

          `event_type` 값은 최대 100자까지 입력할 수 있습니다.

          `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` 이벤트를 사용하면 예약된 시간에 워크플로를 트리거할 수 있습니다.


          **Example:**

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

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

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

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

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"

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

예약된 워크플로의 actor

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

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

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

status

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

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

on:
  status

새 커밋 상태에 따라 워크플로에서 작업을 실행하려는 경우 github.event.state 컨텍스트를 사용할 수 있습니다. 예를 들어 다음 워크플로는 커밋 상태가 변경되면 트리거되지만 새 커밋 상태가 if_error_or_failure 또는 error인 경우에만 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` 이벤트로 트리거되면 호출된 워크플로의 이벤트 페이로드는 호출 워크플로의 이벤트 페이로드와 동일합니다. 자세한 내용은 [AUTOTITLE](/actions/using-workflows/reusing-workflows)을(를) 참조하세요.

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

on: workflow_call

workflow_dispatch

          [workflow_dispatch](/webhooks-and-events/webhooks/webhook-events-and-payloads#workflow_dispatch) | 해당 없음 | 
          `GITHUB_REF` 분기 또는 태그의 마지막 커밋 | 디스패치를 받은 분기 또는 태그 |

워크플로가 수동으로 트리거되도록 하려면 workflow_dispatch 이벤트를 구성해야 합니다. 워크플로 실행은 GitHub API, GitHub CLI, GitHub UI를 통해 수동으로 트리거할 수 있습니다. 자세한 내용은 수동으로 워크플로 실행을(를) 참조하세요.

on: workflow_dispatch

입력 제공

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

이 예에서는 logLevel, tags, 및 environment이라는 입력을 정의합니다. 워크플로를 실행할 때 입력에 대한 값을 워크플로에 전달합니다. 그런 다음, 이 워크플로는 inputs.logLevel, inputs.tags, 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` 를 사용해서는 워크플로 수준을 세 개 이상 연결할 수 없습니다. 예를 들어 초기 워크플로 `B`가 실행된 후 순차적으로 실행되도록 (`F`부터 `A`까지의) 5개의 워크플로를 트리거하려고 하면(즉, `A` → `B` → `C` → `D` → `E` → `F`) `E` 및 `F` 워크플로가 실행되지 않습니다.

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

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

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

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

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` 필터를 사용하여 워크플로를 트리거하기 위해 트리거 워크플로가 실행되어야 하는 분기를 지정할 수 있습니다. 자세한 내용은 [AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#onworkflow_runbranchesbranches-ignore)을(를) 참조하세요. 예를 들어 다음 트리거가 있는 워크플로는 이름이 `Build`인 분기에서 `canary`라는 워크플로가 실행되는 경우에만 실행됩니다.

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

위의 워크플로 실행이 완료되면 다음 워크플로의 실행을 트리거합니다. 다음 워크플로는 github.event.workflow_run 컨텍스트와 GitHub 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@v8
        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',
            });
            const fs = require('fs');
            const path = require('path');
            const temp = '${{ runner.temp }}/artifacts';
            if (!fs.existsSync(temp)){
              fs.mkdirSync(temp);
            }
            fs.writeFileSync(path.join(temp, 'pr_number.zip'), Buffer.from(download.data));

      - name: 'Unzip artifact'
        run: unzip "${{ runner.temp }}/artifacts/pr_number.zip" -d "${{ runner.temp }}/artifacts"

      - 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 = Number(fs.readFileSync(path.join(temp, '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!'
            });