Creating custom deployment protection rules

About custom deployment protection rules

타사 서비스를 사용하여 배포를 제어하는 사용자 지정 보호 규칙을 사용하도록 설정할 수 있습니다. 예를 들어 Datadog, Honeycomb, ServiceNow와 같은 서비스를 사용하여 GitHub에 대한 배포에 자동화된 승인을 제공할 수 있습니다.

Custom deployment protection rules are powered by GitHub Apps and run based on webhooks and callbacks. Approval or rejection of a workflow job is based on consumption of the deployment_protection_rule webhook. For more information, see 웹후크 이벤트 및 페이로드 and Approving or rejecting deployments.

Once you have created a custom deployment protection rule and installed it on your repository, the custom deployment protection rule will automatically be available for all environments in the repository.

Using custom deployment protection rules to approve or reject deployments

Deployments to an environment can be approved or rejected based on the conditions defined in any external service like an approved ticket in an IT Service Management (ITSM) system, vulnerable scan result on dependencies, or stable health metrics of a cloud resource. The decision to approve or reject deployments is at the discretion of the integrating third-party application and the gating conditions you define in them. The following are a few use cases for which you can create a deployment protection rule.

• ITSM & Security Operations: you can check for service readiness by validating quality, security, and compliance processes that verify deployment readiness.
• Observability systems: you can consult monitoring or observability systems (Asset Performance Management Systems and logging aggregators, cloud resource health verification systems, etc.) for verifying the safety and deployment readiness.
• Code quality & testing tools: you can check for automated tests on CI builds which need to be deployed to an environment.

Alternatively, you can write your own protection rules for any of the above use cases or you can define any custom logic to safely approve or reject deployments from pre-production to production environments.

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.
      
   4. To the right of "Deployments," click the drop down menu and select Access: Read and write.
      
   5. Under "Subscribe to events," select Deployment protection rule.
      

2. Install the custom deployment protection rule in your repositories and enable it for use. For more information, see Configuring custom deployment protection rules.

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 Reviewing deployments.