Skip to main content

REST API를 사용하여 검사와 상호 작용

REST API를 사용하여 리포지토리의 코드 변경에 대해 강력한 검사를 실행하는 GitHub Apps을(를) 빌드할 수 있습니다. 연속 통합, 코드 린팅 또는 코드 검사 서비스를 수행하고 커밋에 대한 자세한 피드백을 제공하는 앱을 만들 수 있습니다.

개요

이진 통과/실패 빌드 상태 대신 GitHub Apps는 풍부한 상태를 보고하고, 자세한 정보로 코드 줄에 주석을 달고, 테스트를 다시 실행할 수 있습니다. 검사를 관리하는 REST API는 GitHub 앱에서만 사용할 수 있습니다.

GitHub App에서 REST API를 사용하는 방법에 대한 예제는 "Checks API를 사용하여 CI 테스트 만들기"를 참조하세요.

검사 도구 모음 정보

다른 사용자가 리포지토리에 코드를 푸시할 때 GitHub는 마지막 커밋에 대한 검사 도구 모음을 만듭니다. 검사 도구 모음은 특정 커밋에 대해 단일 GitHub 앱에서 만든 검사 실행의 컬렉션입니다. 검사 도구 모음에는 제품군에 포함된 검사 실행의 상태 및 결론이 요약되어 있습니다.

검사 도구 모음 워크플로

검사 도구 모음은 검사 도구 모음의 conclusion에서 가장 높은 우선 순위 검사 실행 conclusion을 보고합니다. 예를 들어, 세 번의 검사 실행에 timed_out, success, neutral의 결론이 있는 경우 검사 도구 모음 결론은 timed_out입니다.

기본적으로 GitHub는 코드가 리포지토리에 푸시될 때 자동으로 검사 도구 모음을 만듭니다. 이 기본 흐름은 checks:write 권한이 있는 모든 GitHub 앱에 check_suite 이벤트(requested 작업 포함)를 보냅니다. GitHub 앱이 check_suite 이벤트를 수신하면 최신 커밋에 대한 새 검사 실행을 만들 수 있습니다. GitHub는 검사 실행의 리포지토리 및 SHA에 따라 올바른 검사 도구 모음에 새 검사 실행을 자동으로 추가합니다.

기본 자동 흐름을 사용하지 않으려면 검사 도구 모음을 만들 때 제어할 수 있습니다. 검사 도구 모음 만들기에 대한 기본 설정을 변경하려면 검사 도구 모음에 대한 업데이트 리포지토리 기본 설정 엔드포인트를 사용합니다. 자동 흐름 설정에 대한 모든 변경 내용은 리포지토리의 감사 로그에 기록됩니다. 자동 흐름을 사용하지 않도록 설정한 경우 검사 도구 모음 만들기 엔드포인트를 사용하여 검사 도구 모음을 만들 수 있습니다. 계속 검사 실행 만들기 엔드포인트를 사용하여 커밋에 대한 피드백을 제공해야 합니다.

REST API가 검사와 상호 작용할 수 있는 쓰기 권한은 GitHub Apps에서만 사용할 수 있습니다. OAuth Apps 및 인증된 사용자는 검사 실행을 보고 도구 모음을 확인할 수 있지만 만들 수는 없습니다. GitHub App을(를) 빌드하지 않는 경우 REST API를 사용하여 커밋 상태와 상호 작용하는 데 관심이 있을 수 있습니다.

엔드포인트를 사용하여 검사 도구 모음을 관리하려면 GitHub App에 권한이 있어야 checks:write 하며 check_suite 웹후크를 구독할 수도 있습니다.

GitHub 앱으로 인증하는 방법에 대한 자세한 내용은 “GitHub 앱에 대한 인증 옵션”을 참조하세요.

검사 실행 정보

검사 실행은 검사 도구 모음의 일부인 개별 테스트입니다. 각 실행에는 상태 및 결론이 포함됩니다.

검사 실행 워크플로

검사 실행이 14일 넘게 불완전한 상태이면 검사 실행의 conclusionstale이 되며 GitHub에 과 함께 부실한 것으로 나타납니다. GitHub만 검사 실행을 stale로 표시할 수 있습니다. 검사 실행의 가능한 결론에 대한 자세한 내용은 conclusion 매개 변수를 참조하세요.

check_suite 웹후크를 받는 즉시 검사가 완료되지 않은 경우에도 검사 실행을 만들 수 있습니다. 검사 실행이 queued, in_progress 또는 completed 값으로 완료되면 검사 실행의 status를 업데이트할 수 있으며, 더 자세한 정보가 제공되면 output을 업데이트할 수 있습니다. 검사 실행에는 타임스탬프, 외부 사이트의 세부 정보에 대한 링크, 특정 코드 줄에 대한 자세한 주석, 수행된 분석에 대한 정보가 포함될 수 있습니다.

검사 실행 주석

GitHub UI에서 수동으로 검사를 다시 실행할 수도 있습니다. 자세한 내용은 “상태 검사 정보”를 참조하세요. 이 경우 검사 실행을 만든 GitHub 앱은 새 검사 실행을 요청하는 check_run 웹후크를 받게 됩니다. 검사 도구 모음을 만들지 않고 검사 실행을 만드는 경우 GitHub는 자동으로 검사 도구 모음을 만듭니다.

REST API가 검사와 상호 작용할 수 있는 쓰기 권한은 GitHub Apps에서만 사용할 수 있습니다. OAuth Apps 및 인증된 사용자는 검사 실행을 보고 도구 모음을 확인할 수 있지만 만들 수는 없습니다. GitHub App을(를) 빌드하지 않는 경우 REST API를 사용하여 커밋 상태와 상호 작용하는 데 관심이 있을 수 있습니다.

엔드포인트를 사용하여 검사 실행을 관리하려면 GitHub App에 권한이 있어야 checks:write 하며 check_run 웹후크를 구독할 수도 있습니다.

검사 실행 및 요청된 작업

요청된 작업으로 검사 실행을 설정할 때(GitHub Actions와 혼동하지 않음) GitHub의 끌어오기 요청 보기에 사용자가 GitHub App을(를) 요청하여 추가 작업을 수행할 수 있는 단추를 표시할 수 있습니다.

예를 들어 코드 린팅 앱은 요청된 작업을 사용하여 끌어오기 요청에 단추를 표시하여 검색된 구문 오류를 자동으로 수정할 수 있습니다.

앱에서 추가 작업을 요청할 수 있는 단추를 만들려면 검사 실행 만들기actions 개체를 사용합니다. 예를 들어 아래 actions 개체는 끌어오기 요청에 “수정”이라는 레이블이 있는 단추를 표시합니다. 검사 실행이 완료되면 단추가 나타납니다.

"actions": [{
   "label": "Fix this",
   "description": "Let us fix that for you",
   "identifier": "fix_errors"
 }]

요청된 작업 검사 실행 단추

사용자가 단추를 클릭하면 GitHub이(가) check_run.requested_action 웹후크를 앱으로 보냅니다. 앱이 check_run.requested_action 웹후크 이벤트를 받으면 웹후크 페이로드에서 requested_action.identifier 키를 찾아 클릭한 단추를 확인하고 요청된 작업을 수행할 수 있습니다.

REST API를 사용하여 요청된 작업을 설정하는 방법에 대한 자세한 예제는 "Checks API를 사용하여 CI 테스트 만들기"를 참조하세요.

검사 데이터 보존

400일보다 오래된 데이터가 보관되어 있는지 검사합니다. 보관 프로세스의 일부로 GitHub는 해당 커밋에 대한 모든 검사의 상태를 나타내는 롤업 커밋 상태를 만듭니다. 결과적으로 필요한 보관된 검사가 있는 끌어오기 요청의 병합 상자는 차단된 상태이며 끌어오기 요청을 병합하기 전에 검사를 다시 실행해야 합니다.