원격 저장소에서 풀하기

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

GitLab 인터페이스를 사용하여 저장소의 콘텐츠와 활동을 탐색할 수 있습니다.
저장소가 GitLab에 호스팅되지 않더라도 가능합니다.
업스트림 저장소에서 여러분의 저장소로 브랜치, 태그 및 커밋을 복사하기 위해
풀 미러를 생성하세요.

푸시 미러와는 달리, 풀 미러는 일정에 따라
업스트림(원격) 저장소에서 변경 사항을 가져옵니다.
미러가 업스트림 저장소와 분리되지 않도록 하려면
다운스트림 미러에 직접 커밋을 푸시하지 마세요.
대신 업스트림 저장소에 커밋을 푸시하세요.
원격 저장소의 변경 사항은 GitLab 저장소로 가져옵니다:

UI 및 API 업데이트는 기본 풀 미러링 간격
5분에 적용됩니다. 이 간격은 셀프 관리 인스턴스에서 구성할 수 있습니다.

기본적으로, 다운스트림 풀 미러의 어떤 브랜치나 태그가
로컬 저장소와 분리될 경우, GitLab은 브랜치 업데이트를 중지합니다.
이것은 데이터 손실을 방지합니다.
업스트림 저장소에서 삭제된 브랜치 및 태그는
다운스트림 저장소에 반영되지 않습니다.

note
다운스트림 풀 미러 저장소에서 삭제되었으나
업스트림 저장소에는 여전히 있는 항목은 다음 풀 시 복원됩니다.
예를 들어: 미러링된 저장소에서 단지 삭제된 브랜치는
다음 풀 후에 다시 나타납니다.

풀 미러링 작동 방식

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

  1. GitLab은 저장소를 큐에 추가합니다.
  2. 1분마다 Sidekiq 크론 작업이
    다음에 기반하여 저장소 미러 업데이트를 예약합니다:
    • 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에 알리려면 API 호출을 사용할 수 있지만, 풀 미러링 제한을 위한 최소 간격은 여전히 적용됩니다.

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

미러링 시 하드 실패 수정

  • 13.9에서 GitLab Premium으로 이동했습니다.

14회 연속적으로 실패한 재시도 후, 미러링 프로세스는 하드 실패로 표시되며 미러링 시도가 중단됩니다. 이 실패는 다음에서 확인할 수 있습니다:

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

프로젝트 미러링을 재개하려면, 업데이트 강제 실행을 사용하세요.

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

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

관련 주제