상태 검사는 커밋이 리포지토리에 대해 설정된 조건을 충족하는지 여부를 표시합니다. 일반적으로 연속 통합 빌드, 테스트, 코드 검사 또는 배포 검사와 같은 외부 시스템에서 만들어집니다.
상태 검사는 검토자와 유지 관리자가 끌어오기 요청을 병합할 준비가 되었는지 여부를 이해하는 데 도움이 됩니다. 확인 결과 작업이 여전히 실행 중이거나, 변경 내용이 유효성 검사를 통과했거나, 주의가 필요한지 확인할 수 있습니다.
리포지토리에 대한 쓰기 권한이 있는 사용자는 리포지토리의 상태 검사 상태를 설정할 수 있습니다.
보호된 분기에 대한 상태 검사가 필요한 경우 끌어오기 요청을 병합하기 전에 전달해야 합니다. 보호된 분기 정보을(를) 참조하세요.
참고
건너뛴 작업은 해당 상태를 “성공”으로 보고합니다. 필요한 검사인 경우에도 끌어오기 요청이 병합되는 것을 방지하지 않습니다.
상태 검사 유형 GitHub
다음과 같은 두 가지 유형의 상태 검사가 있습니다.GitHub
| Type | 상세 수준 | 만든 사람: |
|---|---|---|
| 수표 | 자세한 출력, 주석 및 메시지 | |
| GitHub Apps를 포함합니다 GitHub Actions. | ||
| 커밋 상태 | 커밋에 대한 더 간단한 상태입니다. | 외부 서비스 및 통합. |
참고
GitHub Actions 는 워크플로가 실행되면 커밋 상태가 아닌 검사를 생성합니다.
리포지토리에 대한 푸시 액세스 권한이 있는 조직 소유자 및 사용자는 's API를 사용하여 GitHub검사를 만들고 상태를 커밋할 수 있습니다. 검사에 대한 REST API 엔드포인트 및 커밋 상태에 대한 REST API 엔드포인트을(를) 참조하세요.
수표
검사에는 빌드 로그, 테스트 결과, 주석 및 자세한 내용에 대한 링크가 포함될 수 있습니다. 끌어오기 요청에서 검사 탭은 실행된 유효성 검사와 검사가 통과되거나 실패한 이유를 이해하는 데 도움이 됩니다.
참고
검사 탭은 리포지토리에 대한 커밋 상태가 아닌 검사를 설정한 경우에만 끌어오기 요청에 대해 채워집니다.
확인란이 특정 줄을 가리키면 끌어오기 요청의 파일 탭에도 세부 정보가 나타날 수 있습니다. 이렇게 하면 검토자가 자동화된 피드백을 변경 중인 코드에 연결할 수 있습니다.
개별 커밋에 대한 검사 건너뛰기 및 요청
일부 리포지토리에서는 개별 커밋에 대한 검사를 건너뛰거나 요청할 수 있습니다. 이는 검사가 특정 변경 내용과 관련이 없거나 검사가 자동으로 요청되지 않는 경우에 유용할 수 있습니다.
워크플로의 경우 GitHub Actions 커밋 메시지에 건너뛰기 명령을 포함하여 이벤트 및 pull_request 이벤트에 의해 push 트리거되는 워크플로 실행을 건너뛸 수 있습니다.
워크플로 실행 건너뛰기을(를) 참조하세요.
또는 커밋에 대한 모든 확인을 건너뛰거나 요청하려면, 커밋 메시지 끝에 다음 트레일러 라인 중 하나를 추가하세요.
-
커밋에 대한 확인을 건너뛰려면 커밋 메시지와 변경 내용에 대한 짧고 의미 있는 설명을 입력합니다. 커밋 설명 뒤 닫는 따옴표 앞에 빈 줄 두 개를 추가하고 그 뒤에
skip-checks: true을 추가합니다.$ git commit -m "Update README > > skip-checks: true" -
커밋 확인을 _요청_하려면 커밋 메시지와 변경 내용에 대한 짧고 의미 있는 설명을 입력합니다. 커밋 설명 뒤 닫는 따옴표 앞에 빈 줄 두 개를 추가하고 그 뒤에
request-checks: true을 추가합니다.$ git commit -m "Refactor usability tests > > request-checks: true"
기본적으로 Git은 연속된 줄임표를 자동으로 제거합니다. 입력한 대로 커밋 메시지를 그대로 두려면 커밋에 --cleanup=verbatim 옵션을 사용합니다. 자세한 내용은 Git 설명서의 --cleanup=<mode>를 참조하세요.
확인 상태 및 결론
실행될 때 상태를 통해 이동한 다음, 완료되면 결론을 받습니다. 일부 상태는 수동으로 설정할 수 없으며 예약되어 GitHub Actions있습니다.
| 상태 | Description |
GitHub Actions 만? |
| --- | --- | --- |
| completed | 확인 실행이 완료되었으며 결론이 있습니다(아래 참조). | No |
| expected | 확인 실행이 상태 보고를 기다리고 있습니다. | 예 |
| failure | 검사 실행이 실패했습니다. | No |
| in_progress | 검사 실행 중입니다. | No |
| pending | 확인 실행이 대기열의 맨 앞에 있지만 그룹 기반 동시 실행 한도에 도달했습니다. | 예 |
| queued | 확인 실행이 대기열에 추가되었습니다. | No |
| requested | 확인 실행이 생성되었지만 대기열에 추가되지 않았습니다. | 예 |
| startup_failure | 확인 세트가 시작 중에 실패했습니다. 이 상태는 확인 실행에는 적용되지 않습니다. | 예 |
| waiting | 검사 실행이 배포 보호 규칙이 충족되기를 기다리고 있습니다. | 예 |
확인의 상태가 completed일 때, 결론이 있습니다. 성공적인 결론은 일반적으로 검사가 병합을 차단하지 않음을 의미합니다. 오류, 시간 제한 또는 작업이 필요한 결론은 일반적으로 끌어오기 요청이 병합되기 전에 누군가가 세부 정보를 검토해야 한다는 것을 의미합니다.
| Conclusion | Description |
|---|---|
action_required | 확인 실행이 완료되면 필요한 작업이 제공되었습니다. 자세한 내용은 REST API를 사용하여 검사와 상호작용하기을(를) 참조하세요. |
cancelled | 확인 실행이 완료되기 전에 취소되었습니다. |
failure | 검사 실행이 실패했습니다. |
neutral | 확인 실행이 중립적인 결과로 완료되었습니다. 이는 종속 체크 인의 성공으로 처리됩니다 GitHub Actions. |
skipped | 검사 실행을 건너뛰었습니다. 이는 종속 체크 인의 성공으로 처리됩니다 GitHub Actions. |
stale | 검사 실행이 너무 오래 걸렸기 때문에 부실한 GitHub 것으로 표시되었습니다. |
success | 검사 실행이 성공적으로 완료되었습니다. |
timed_out | 검사 실행 시간을 초과했습니다. |
검사 보존
GitHub 는 400일 동안 검사 데이터를 보존합니다. 400일이 지나면 데이터가 보관됩니다. 보관 후 10일이 지나면 데이터가 영구적으로 삭제됩니다.
끌어오기 요청을 필수 및 보관된 검사와 병합하려면 검사를 다시 실행해야 합니다.