원격 저장소에서 가져오기

Tier: Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated
  • 13.9에서 GitLab Premium으로 이전되었습니다.

GitLab 인터페이스를 사용하여 저장소의 콘텐츠 및 활동을 찾아볼 수 있습니다. 심지어 GitLab에 호스팅되지 않은 저장소의 내용도 복사하여 여러 가지 브랜치, 태그 및 커밋들을 만들 수 있습니다. 미러를 만들어 기존 원격 저장소의 변경 사항을 복사하세요.

푸시 미러와는 달리, 풀 미러는 일정 기간마다 상향(원격) 저장소에서 변경 사항을 검색합니다. 상향(원격) 저장소에 커밋을 직접 푸시하지 않고 하위 미러에 커밋을 푸시하여 상향(원격) 저장소와 다른 경로로 미러가 차이 나지 않도록하세요. 원격 저장소의 변경 사항은 GitLab 저장소로 풀됩니다:

UI 및 API 업데이트는 5분 기본 풀 미러링 간격에 따라 진행됩니다. 이 간격은 Self-managed 인스턴스에서 구성할 수 있습니다.

기본적으로 하위 풀 미러에서 로컬 저장소와 다른 브랜치나 태그가 있는 경우 GitLab은 해당 브랜치의 업데이트를 중지합니다. 이는 데이터 손실을 방지합니다. 상향 저장소에서 삭제된 브랜치나 태그는 하향 저장소에 반영되지 않습니다.

note
하위 풀 미러 저장소에서 삭제되었지만 상향 저장소에 아직 있는 항목은 다음 풀 후에 복원됩니다. 예: 미러 저장소에서만 삭제된 브랜치는 다음 풀 후에 다시 나타납니다.

풀 미러링 작동 방식

GitLab 저장소를 풀 미러로 구성한 후:

  1. GitLab은 저장소를 대기열에 추가합니다.
  2. 매분마다 Sidekiq cron 작업이 실행되어 저장소 미러의 업데이트 일정을 기반으로 예약됩니다:
    • Sidekiq 설정에 따라 결정된 사용 가능한 용량. GitLab.com의 경우 GitLab.com Sidekiq 설정 참조.
    • 대기중인 미러 수 및 업데이트가 예약된 횟수에 따라 결정됩니다. 예약된 업데이트가 언제 일어나는지는 저장소 미러의 마지막 업데이트 및 업데이트 재시도 횟수에 따라 달라집니다.
  3. Sidekiq에서 업데이트를 처리할 수 있으면 미러가 업데이트됩니다. 업데이트 프로세스가:
    • 성공하면 최소 30분 대기 후 다시 업데이트 예약됩니다.
    • 실패하면 나중에 다시 시도됩니다. 14번의 실패 후, 미러는 강한 실패로 표시되어 더 이상 업데이트를 예약하지 않습니다. 가지가 상향 저장소와 다르게 되는 것이 실패의 원인이 될 수 있습니다. 가지가 다르게 되는 것을 방지하려면 미러를 만들 때 가지가 다른 경우 덮어쓰기를 구성하세요.

풀 미러링 구성

전제 조건:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 설정 > 저장소를 선택합니다.
  3. 저장소 미러링을 확장합니다.

  4. Git 저장소 URL을 입력하세요.

    note
    gitlab 저장소를 미러링하려면 gitlab.com:gitlab-org/gitlab.git 또는 https://gitlab.com/gitlab-org/gitlab.git을 사용하세요.
  5. 미러 방향에서 풀을 선택합니다.
  6. 인증 방법에서 인증 방법을 선택하세요. 자세한 내용은 미러 인증 방법을 참조하세요.
  7. 필요한 옵션을 선택하세요:
  8. 구성을 저장하려면 저장소 미러링을 선택하세요.

가지가 다른 경우 덮어쓰기

  • 13.9에서 GitLab Premium으로 이전되었습니다.

원격 브랜치가 로컬 버전과 달라지더라도 항상 로컬 브랜치를 업데이트하려면 미러를 만들 때 가지가 다르면 덮어쓰기를 선택하세요.

주의: 미러된 브랜치의 경우, 이 옵션을 활성화하면 로컬 변경 사항이 손실됩니다.

미러 업데이트할 때 파이프라인 트리거

  • 13.9에서 GitLab Premium으로 이전되었습니다.

이 옵션이 활성화된 경우, 브랜치 또는 태그가 원격 저장소에서 업데이트될 때 파이프라인이 트리거됩니다. 원격 저장소의 활동에 따라 CI 실행기에 부하가 크게 증가할 수 있습니다. 부하를 처리할 수 있다고 확신되면 이 기능을 사용하세요. CI는 풀 미러링 설정 시 할당된 자격 증명을 사용합니다.

API 호출을 사용하여 업데이트 트리거

  • 13.9에서 GitLab Premium으로 이전되었습니다.

풀 미러링은 폴링을 사용하여 상향(원격)에서 새 브랜치 및 커밋을 감지합니다. 그 후 몇 분 후에 GitLab에 알릴 수 있습니다. 하지만 풀 미러링 최소 간격 제한이 여전히 적용됩니다.

자세한 내용은 프로젝트를 위해 풀 미러링 프로세스 시작를 참조하세요.

미러링 중 강한 실패 수정

  • 13.9에서 GitLab Premium으로 이전되었습니다.

연속적으로 14번의 실패 후, 미러링 프로세스가 강한 실패로 표시되고 미러링 시도가 중지됩니다. 이 실패는 다음 위치에서 확인할 수 있습니다:

  • 프로젝트의 메인 대시보드.
  • 풀 미러 설정 페이지.

프로젝트 미러링을 계속하려면 강제로 업데이트하세요.

긴 네트워크 또는 서버 중단 후 같은 문제로 여러 프로젝트가 영향을 받으면, 다음 명령을 사용하여 모든 영향받는 프로젝트를 식별하고 업데이트할 수 있습니다: 

Project.find_each do |p|
  if p.import_state && p.import_state.retry_count >= 14
    puts "Resetting mirroring operation for #{p.full_path}"
    p.import_state.reset_retry_count
    p.import_state.set_next_execution_to_now(prioritized: true)
    p.import_state.save!
  end
end

관련 주제