Creating custom deployment protection rules

Use GitHub Apps to automate protecting deployments with third-party systems.

누가 이 기능을 사용할 수 있나요?

사용자 지정 배포 보호 규칙은 모든 플랜의 퍼블릭 리포지토리에서 사용할 수 있습니다. 프라이빗 또는 내부 리포지토리의 사용자 지정 배포 보호 규칙에 액세스하려면 GitHub Enterprise를 사용해야 합니다.

이 문서의 내용

Prerequisites

참고 항목

사용자 지정 배포 보호 규칙은 현재 공개 미리 보기 버전이며 변경될 수 있습니다.

For general information about deployment protection rules, see Deploying with GitHub Actions.

Creating a custom deployment protection rule with GitHub Apps

  1. Create a GitHub App. For more information, see GitHub 앱 등록. Configure the GitHub App as follows.

    1. Optionally, in the Callback URL text field under "Identifying and authorizing users," enter the callback URL. For more information, see 사용자 권한 부여 콜백 URL 정보.
    2. Under "Permissions," select Repository permissions.
    3. To the right of "Actions," click the drop down menu and select Access: Read-only.
      Screenshot of the "Repository permissions" section for a new GitHub App. The Actions permission shows "Read-only" and is outlined in orange.
    4. To the right of "Deployments," click the drop down menu and select Access: Read and write.
      Screenshot of the "Repository permissions" section for a new GitHub App. The Deployments permission shows "Read and write" and is outlined in orange.
    5. Under "Subscribe to events," select Deployment protection rule.
      Screenshot of the "Subscribe to events section" section for a new GitHub App. The checkbox for the Deployment protection rule is outlined in orange.

  2. Install the custom deployment protection rule in your repositories and enable it for use. For more information, see 사용자 지정 배포 보호 규칙 구성.

Approving or rejecting deployments

Once a workflow reaches a job that references an environment that has the custom deployment protection rule enabled, GitHub sends a POST request to a URL you configure containing the deployment_protection_rule payload. You can write your deployment protection rule to automatically send REST API requests that approve or reject the deployment based on the deployment_protection_rule payload. Configure your REST API requests as follows.

  1. Validate the incoming POST request. For more information, see 웹후크 제공 유효성 검사하기.

  2. Use a JSON Web Token to authenticate as a GitHub App. For more information, see GitHub 앱으로 인증.

  3. Using the installation ID from the deployment_protection_rule webhook payload, generate an install token. For more information, see GitHub 앱을 사용한 인증 정보.

    curl --request POST \
--url "http(s)://HOSTNAME/api/v3/app/installations/INSTALLATION_ID/ACCESS_TOKENS" \
--header "Accept: application/vnd.github+json" \
--header "Authorization: Bearer {jwt}" \
--header "Content-Type: application/json" \
--data \
'{ \
   "repository_ids": [321], \
   "permissions": { \
      "deployments": "write" \
   } \
}'

  4. Optionally, to add a status report without taking any other action to GitHub, send a POST request to /repos/OWNER/REPO/actions/runs/RUN_ID/deployment_protection_rule. In the request body, omit the state. For more information, see 워크플로 실행에 대한 REST API 엔드포인트. You can post a status report on the same deployment up to 10 times. Status reports support Markdown formatting and can be up to 1024 characters long.

  5. To approve or reject a request, send a POST request to /repos/OWNER/REPO/actions/runs/RUN_ID/deployment_protection_rule. In the request body, set the state property to either approved or rejected. For more information, see 워크플로 실행에 대한 REST API 엔드포인트.

  6. Optionally, request the status of an approval for a workflow run by sending a GET request to /repos/OWNER/REPOSITORY_ID/actions/runs/RUN_ID/approvals. For more information, see 워크플로 실행에 대한 REST API 엔드포인트.

  7. Optionally, review the deployment on GitHub. For more information, see 배포 검토.