InfoGrab Docs

외부 커밋 상태

요약

외부 커밋 상태를 사용하면 Jenkins, CircleCI 또는 사용자 정의 배포 도구와 같은 외부 CI/CD 시스템이 GitLab 파이프라인과 통합할 수 있습니다. 외부 시스템이 Commits API를 사용하여 커밋 상태를 게시하면 GitLab은 이러한 상태를 기존 파이프라인에 추가하거나 새 파이프라인을 생성하여 처리합니다.

외부 커밋 상태를 사용하면 Jenkins, CircleCI 또는 사용자 정의 배포 도구와 같은 외부 CI/CD 시스템이 GitLab 파이프라인과 통합할 수 있습니다. 외부 시스템이 GitLab에 커밋 상태를 게시하면 상태 결과가 머지 리퀘스트 및 커밋 보기에서 CI/CD 잡과 함께 표시됩니다.

외부 시스템이 Commits API를 사용하여 커밋 상태를 게시하면 GitLab은 이러한 상태를 기존 파이프라인에 추가하거나 새 파이프라인을 생성하여 처리합니다.

파이프라인 선택#

외부 시스템에서 커밋 상태를 게시하면 찾기 또는 생성 방식이 사용됩니다:

  1. GitLab은 주어진 커밋 SHA 및 ref에 대한 가장 최근의 non-archived CI 파이프라인을 검색합니다. pipeline_id 매개변수를 포함하여 파이프라인을 직접 검색할 수도 있습니다.
  2. GitLab이 적합한 파이프라인을 찾으면 새 잡 상태를 해당 파이프라인에 추가합니다. 기존 파이프라인에 추가된 잡의 경우 CI_PIPELINE_SOURCE는 파이프라인 소스(예: push 또는 merge_request_event)와 일치합니다.
  3. 적합한 파이프라인이 없으면 GitLab은 잡을 포함할 새 파이프라인을 생성합니다. 새 파이프라인의 경우 CI_PIPELINE_SOURCE는 external입니다.

외부 잡 상태는 다른 GitLab CI/CD 스테이지와 별도로 파이프라인의 external 스테이지에 표시됩니다.

Warning

동일한 커밋에 대해 중복 파이프라인이 존재하는 경우 외부 상태 배치가 모호해집니다. GitLab은 newest_first를 사용하여 최신 파이프라인을 선택하지만 동시 파이프라인 생성으로 인해 외부 상태가 예상치 못한 파이프라인에 나타나거나 머지 리퀘스트 보기에서 보이지 않을 수 있습니다.

중복 파이프라인을 방지하거나 pipeline_id로 파이프라인을 직접 대상으로 지정하려면 워크플로우 규칙을 구성하세요.

잡 업데이트 및 재시도#

외부 시스템에서 커밋 상태를 게시할 때:

  • 동일한 name, user, sha를 가진 running 또는 pending 잡이 대상 파이프라인에 이미 있으면 GitLab은 해당 상태를 업데이트합니다.
    • 다른 사용자가 동일한 name을 가진 잡을 업데이트하면 잡이 재시도됩니다. 이렇게 하면 새 잡이 생성되고 이전 잡은 현재 파이프라인에서 숨겨집니다.
  • running 또는 pending 상태가 아닌 잡을 동일한 name이지만 다른 status로 재시도할 수 있습니다(예: failed로 표시된 잡에 대해 success 전송). 이렇게 하면 새 잡이 생성되고 이전 잡은 현재 파이프라인에서 숨겨집니다.
  • 고유한 잡 name을 사용하여 다른 외부 서비스가 동일한 SHA 및 파이프라인에 잡을 추가할 수 있습니다.

SHA/ref 조합에 대한 업데이트가 이미 진행 중인 경우 409 오류가 반환됩니다. 이 오류를 처리하려면 요청을 재시도하세요.

문제 해결#

머지 리퀘스트에서 외부 상태가 보이지 않음#

외부 CI 상태가 머지 리퀘스트 파이프라인에 나타나지 않는 경우:

  1. 동일한 커밋에 대해 머지 리퀘스트 파이프라인과 브랜치 파이프라인이 모두 실행되고 있는지 확인합니다.
  2. 워크플로우 규칙이 중복 파이프라인을 방지하는지 확인합니다.
  3. 외부 시스템이 올바른 ref에 게시하고 있는지 확인합니다.
  4. 커밋이 머지 리퀘스트와 연결된 경우 API 호출이 머지 리퀘스트의 소스 브랜치의 커밋을 대상으로 하는지 확인합니다.

자세한 내용은 중복 파이프라인 방지를 참조하세요.

외부 커밋 상태

Tier: Free, Premium, Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
원문 보기
요약

외부 커밋 상태를 사용하면 Jenkins, CircleCI 또는 사용자 정의 배포 도구와 같은 외부 CI/CD 시스템이 GitLab 파이프라인과 통합할 수 있습니다. 외부 시스템이 Commits API를 사용하여 커밋 상태를 게시하면 GitLab은 이러한 상태를 기존 파이프라인에 추가하거나 새 파이프라인을 생성하여 처리합니다.

외부 커밋 상태를 사용하면 Jenkins, CircleCI 또는 사용자 정의 배포 도구와 같은 외부 CI/CD 시스템이 GitLab 파이프라인과 통합할 수 있습니다. 외부 시스템이 GitLab에 커밋 상태를 게시하면 상태 결과가 머지 리퀘스트 및 커밋 보기에서 CI/CD 잡과 함께 표시됩니다.

외부 시스템이 Commits API를 사용하여 커밋 상태를 게시하면 GitLab은 이러한 상태를 기존 파이프라인에 추가하거나 새 파이프라인을 생성하여 처리합니다.

파이프라인 선택#

외부 시스템에서 커밋 상태를 게시하면 찾기 또는 생성 방식이 사용됩니다:

  1. GitLab은 주어진 커밋 SHA 및 ref에 대한 가장 최근의 non-archived CI 파이프라인을 검색합니다. pipeline_id 매개변수를 포함하여 파이프라인을 직접 검색할 수도 있습니다.
  2. GitLab이 적합한 파이프라인을 찾으면 새 잡 상태를 해당 파이프라인에 추가합니다. 기존 파이프라인에 추가된 잡의 경우 CI_PIPELINE_SOURCE는 파이프라인 소스(예: push 또는 merge_request_event)와 일치합니다.
  3. 적합한 파이프라인이 없으면 GitLab은 잡을 포함할 새 파이프라인을 생성합니다. 새 파이프라인의 경우 CI_PIPELINE_SOURCE는 external입니다.

외부 잡 상태는 다른 GitLab CI/CD 스테이지와 별도로 파이프라인의 external 스테이지에 표시됩니다.

Warning

동일한 커밋에 대해 중복 파이프라인이 존재하는 경우 외부 상태 배치가 모호해집니다. GitLab은 newest_first를 사용하여 최신 파이프라인을 선택하지만 동시 파이프라인 생성으로 인해 외부 상태가 예상치 못한 파이프라인에 나타나거나 머지 리퀘스트 보기에서 보이지 않을 수 있습니다.

중복 파이프라인을 방지하거나 pipeline_id로 파이프라인을 직접 대상으로 지정하려면 워크플로우 규칙을 구성하세요.

잡 업데이트 및 재시도#

외부 시스템에서 커밋 상태를 게시할 때:

  • 동일한 name, user, sha를 가진 running 또는 pending 잡이 대상 파이프라인에 이미 있으면 GitLab은 해당 상태를 업데이트합니다.
    • 다른 사용자가 동일한 name을 가진 잡을 업데이트하면 잡이 재시도됩니다. 이렇게 하면 새 잡이 생성되고 이전 잡은 현재 파이프라인에서 숨겨집니다.
  • running 또는 pending 상태가 아닌 잡을 동일한 name이지만 다른 status로 재시도할 수 있습니다(예: failed로 표시된 잡에 대해 success 전송). 이렇게 하면 새 잡이 생성되고 이전 잡은 현재 파이프라인에서 숨겨집니다.
  • 고유한 잡 name을 사용하여 다른 외부 서비스가 동일한 SHA 및 파이프라인에 잡을 추가할 수 있습니다.

SHA/ref 조합에 대한 업데이트가 이미 진행 중인 경우 409 오류가 반환됩니다. 이 오류를 처리하려면 요청을 재시도하세요.

문제 해결#

머지 리퀘스트에서 외부 상태가 보이지 않음#

외부 CI 상태가 머지 리퀘스트 파이프라인에 나타나지 않는 경우:

  1. 동일한 커밋에 대해 머지 리퀘스트 파이프라인과 브랜치 파이프라인이 모두 실행되고 있는지 확인합니다.
  2. 워크플로우 규칙이 중복 파이프라인을 방지하는지 확인합니다.
  3. 외부 시스템이 올바른 ref에 게시하고 있는지 확인합니다.
  4. 커밋이 머지 리퀘스트와 연결된 경우 API 호출이 머지 리퀘스트의 소스 브랜치의 커밋을 대상으로 하는지 확인합니다.

자세한 내용은 중복 파이프라인 방지를 참조하세요.