# REST API를 사용하여 검사와 상호작용하기 REST API를 사용하여 리포지토리의 코드 변경 내용에 대해 강력한 검사를 실행하는 빌드 GitHub Apps 할 수 있습니다. 연속 통합, 코드 린팅 또는 코드 검사 서비스를 수행하고 커밋에 대한 자세한 피드백을 제공하는 앱을 만들 수 있습니다. ## 개요 통과/실패만 표시하는 단순한 빌드 상태 대신, GitHub Apps는 풍부한 상태 정보를 보고하고 코드 줄마다 자세한 정보를 주석으로 표시하며 테스트를 다시 실행할 수 있습니다. 검사를 관리하는 REST API는 GitHub 앱에서만 사용할 수 있습니다. REST API를 사용하는 방법에 대한 예제는 GitHub App을 [](/ko/enterprise-server@3.22/apps/creating-github-apps/writing-code-for-a-github-app/building-ci-checks-with-a-github-app#step-26-automatically-fix-rubocop-errors)참조하세요. [보호된 브랜치](/ko/enterprise-server@3.22/rest/repos#branches)에서 상태를 사용하여 사람들이 풀 리퀘스트를 조기에 병합하지 못하도록 할 수 있습니다. 자세한 내용은 [보호된 분기 정보](/ko/enterprise-server@3.22/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging)을(를) 참조하세요. ## 체크 스위트 정보 다른 사용자가 리포지토리에 코드를 푸시하면 GitHub 마지막 커밋에 대한 확인 도구 모음을 만듭니다. 확인 도구 모음은 단일 GitHub 앱이 특정 커밋에 대해 만든 [검사 실행](/ko/enterprise-server@3.22/rest/checks#check-runs)의 모음입니다. 검사 도구 모음에는 제품군에 포함된 검사 실행의 상태 및 결론이 요약되어 있습니다. `status`는 `queued`, `in_progress`, `requested`, `waiting`, `pending` 또는 `completed`일 수 있습니다. GitHub Actions만 상태를 `requested`, `waiting` 또는 `pending`(으)로 설정할 수 있습니다. 상태가 `completed`인 경우 결론은 다음 중 어느 것이든 될 수 있습니다. * `action_required` * `cancelled` * `timed_out` * `failure` * `neutral` * `skipped` * `stale` * `startup_failure` * `success` 검사 도구 모음은 검사 도구 모음의 `conclusion`에서 가장 높은 우선 순위 검사 실행 `conclusion`을 보고합니다. 예를 들어, 세 번의 검사 실행에 `timed_out`, `success`, `neutral`의 결론이 있는 경우 검사 도구 모음 결론은 `timed_out`입니다. 기본적으로 GitHub 코드가 리포지토리에 푸시될 때 자동으로 check suite를 만듭니다. 이 기본 흐름은 `check_suite` 이벤트(`requested` 작업 포함)를 `checks:write` 권한이 있는 모든 GitHub 앱에 보냅니다. GitHub 앱이 `check_suite` 이벤트를 받으면 최신 커밋에 대한 새 검사 실행을 만들 수 있습니다. GitHub는 검사 실행의 리포지토리 및 SHA에 따라 올바른 [검사 모음](/ko/enterprise-server@3.22/rest/checks#check-suites)에 새 검사 실행을 자동으로 추가합니다. 기본 자동 흐름을 사용하지 않으려면 검사 도구 모음을 만들 때 제어할 수 있습니다. 검사 도구 모음 만들기에 대한 기본 설정을 변경하려면 [검사 도구 모음에 대한 업데이트 리포지토리 기본 설정](/ko/enterprise-server@3.22/rest/checks/suites#update-repository-preferences-for-check-suites) 엔드포인트를 사용합니다. 자동 흐름 설정에 대한 모든 변경 내용은 리포지토리의 감사 로그에 기록됩니다. 자동 흐름을 사용하지 않도록 설정한 경우 [검사 도구 모음 만들기](/ko/enterprise-server@3.22/rest/checks/suites#create-a-check-suite) 엔드포인트를 사용하여 검사 도구 모음을 만들 수 있습니다. 계속 [검사 실행 만들기](/ko/enterprise-server@3.22/rest/checks/runs#create-a-check-run) 엔드포인트를 사용하여 커밋에 대한 피드백을 제공해야 합니다. REST API가 검사와 상호 작용할 수 있는 쓰기 권한은 GitHub Apps에서만 사용할 수 있습니다. OAuth apps 및 인증된 사용자는 검사 실행을 보고 제품군을 확인할 수 있지만 만들 수는 없습니다. GitHub App을(를) 빌드하지 않는 경우 REST API를 사용하여 [커밋 상태](/ko/enterprise-server@3.22/rest/commits#commit-statuses)와 상호 작용하는 데 관심이 있을 수 있습니다. 검사 모음을 관리하는 엔드포인트를 사용하려면 GitHub App에 `checks:write` 권한이 있어야 하며, [check\_suite](/ko/enterprise-server@3.22/webhooks/webhook-events-and-payloads#check_suite) 웹훅도 구독할 수 있습니다. GitHub 앱으로 인증하는 방법에 대한 자세한 내용은 [GitHub 앱을 사용한 인증 정보](/ko/enterprise-server@3.22/apps/creating-github-apps/authenticating-with-a-github-app/about-authentication-with-a-github-app)을(를) 참조하세요. ## 검사 실행 정보 검사 실행은 검사 도구 모음의 일부인 개별 테스트입니다. 각 실행에는 상태 및 결론이 포함됩니다. `status`는 `queued`, `in_progress`, `requested`, `waiting`, `pending` 또는 `completed`일 수 있습니다. GitHub Actions만 상태를 `requested`, `waiting` 또는 `pending`(으)로 설정할 수 있습니다. 상태가 `completed`인 경우 결론은 다음 중 어느 것이든 될 수 있습니다. * `action_required` * `cancelled` * `timed_out` * `failure` * `neutral` * `skipped` * `success` 검사 실행이 14일 이상 불완전한 상태로 유지되면 해당 검사 실행의 `conclusion`이(가) `stale`(으)로 변경되고, GitHub에서는 와 함께 오래된 상태로 표시됩니다. 오직 GitHub만 검사 실행을 `stale`로 표시할 수 있습니다. 검사 실행의 가능한 결론에 대한 자세한 내용은 [`conclusion` 매개 변수](/ko/enterprise-server@3.22/rest/checks#create-a-check-run--parameters)를 참조하세요. [ `check_suite` ](/ko/enterprise-server@3.22/webhooks/webhook-events-and-payloads#check_suite) 웹후크를 받는 즉시 검사가 완료되지 않은 경우에도 검사 실행을 만들 수 있습니다. 검사 실행이 `status`, `queued` 또는 `in_progress` 값으로 완료되면 검사 실행의 `completed`를 업데이트할 수 있으며, 더 자세한 정보가 제공되면 `output`을 업데이트할 수 있습니다. 검사 실행에는 타임스탬프, 외부 사이트의 세부 정보에 대한 링크, 특정 코드 줄에 대한 자세한 주석, 수행된 분석에 대한 정보가 포함될 수 있습니다. 주석은 검사 실행의 정보를 특정 코드 줄에 추가합니다. 각 주석에는 `annotation_level` 속성을 포함하며 `notice`, `warning`, `failure` 할 수 있습니다. 주석은 `path`, `start_line`, `end_line`도 포함하며 주석이 참조하는 위치를 지정합니다. 주석에는 결과를 설명하는 `message`가 포함됩니다. 자세한 내용은 [검사 실행에 대한 REST API 엔드포인트](/ko/enterprise-server@3.22/rest/checks/runs)을(를) 참조하세요. GitHub UI에서 수동으로 검사를 다시 실행할 수도 있습니다. 자세한 내용은 [상태 검사](/ko/enterprise-server@3.22/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks#checks)을(를) 참조하세요. 이 경우 GitHub App 검사 실행을 만든 경우 새 검사 실행을 요청하는 웹후크를 받게 [`check_run`](/ko/enterprise-server@3.22/webhooks/webhook-events-and-payloads#check_run) 됩니다. 검사 스위트를 생성하지 않고 검사 실행을 생성하면, GitHub가 자동으로 검사 스위트를 생성합니다. REST API가 검사와 상호 작용할 수 있는 쓰기 권한은 GitHub Apps에서만 사용할 수 있습니다. OAuth apps 및 인증된 사용자는 검사 실행을 보고 제품군을 확인할 수 있지만 만들 수는 없습니다. GitHub App을(를) 빌드하지 않는 경우 REST API를 사용하여 [커밋 상태](/ko/enterprise-server@3.22/rest/commits#commit-statuses)와 상호 작용하는 데 관심이 있을 수 있습니다. 체크 실행을 관리하는 엔드포인트를 사용하려면 GitHub App에 `checks:write` 권한이 있어야 하며, [check\_run](/ko/enterprise-server@3.22/webhooks/webhook-events-and-payloads#check_run) 웹후크를 구독할 수도 있습니다. ## 검사 실행 및 요청된 작업 요청된 작업(GitHub Actions와 혼동하지 마세요)으로 체크 실행을 설정하면, GitHub의 pull request 보기에서 사용자가 GitHub App에 추가 작업 수행을 요청할 수 있는 버튼을 표시할 수 있습니다. 예를 들어 코드 린팅 앱은 요청된 작업을 사용하여 끌어오기 요청에 단추를 표시하여 검색된 구문 오류를 자동으로 수정할 수 있습니다. 앱에서 추가 작업을 요청할 수 있는 단추를 만들려면 `actions`\[[](/ko/enterprise-server@3.22/rest/checks/runs#create-a-check-run--parameters) 개체]\(/rest/checks#create-a-check-run)를 사용합니다. 예를 들어 아래 `actions` 개체는 끌어오기 요청의 **검사** 탭에 “수정”이라는 레이블이 있는 단추를 표시합니다. 검사 실행이 완료되면 단추가 나타납니다. ```json "actions": [{ "label": "Fix this", "description": "Let us fix that for you", "identifier": "fix_errors" }] ``` 사용자가 단추를 GitHub 클릭하면 [웹후크를 앱으로 보냅니다`check_run.requested_action`](/ko/enterprise-server@3.22/webhooks/webhook-events-and-payloads#check_run). 앱이 `check_run.requested_action` 웹후크 이벤트를 받으면 웹후크 페이로드에서 `requested_action.identifier` 키를 찾아 클릭한 단추를 확인하고 요청된 작업을 수행할 수 있습니다. REST API를 사용하여 요청된 동작을 설정하는 방법에 대한 자세한 예제는 [GitHub 앱을 사용하여 CI 검사 빌드](/ko/enterprise-server@3.22/apps/creating-github-apps/writing-code-for-a-github-app/building-ci-checks-with-a-github-app)을(를) 참조하세요. ## 검사 데이터 보존 사이트 관리자는 에 대한 검사 데이터에 대한 보존 정책을 제어할 수 있습니다 GitHub Enterprise Server 인스턴스. 자세한 내용은 [애플리케이션 구성](/ko/enterprise-server@3.22/admin/configuring-settings/configuring-user-applications-for-your-enterprise/configuring-applications#enabling-retention-policy-for-checks)을(를) 참조하세요. 끌어오기 요청을 필수 및 보관된 검사와 병합하려면 검사를 다시 실행해야 합니다.