InfoGrab DocsInfoGrab Docs

Bitbucket Server 임포터 개발자 문서

요약

임포트를 테스트하려면 로컬에서 실행 중인 Bitbucket Server 인스턴스가 필요합니다. 임포터의 코드베이스는 다음 디렉터리들로 구성되어 있습니다: lib/gitlab/bitbucket_server_import: 이 디렉터리에는 리소스 임포트에 사용되는 클래스 등 대부분의 코드가 포함되어 있습니다.

사전 요구 사항#

임포트를 테스트하려면 로컬에서 실행 중인 Bitbucket Server 인스턴스가 필요합니다. 로컬 인스턴스 실행 방법은 이 지침을 참조하세요.

코드 구조#

임포터의 코드베이스는 다음 디렉터리들로 구성되어 있습니다:

  • lib/gitlab/bitbucket_server_import: 이 디렉터리에는 리소스 임포트에 사용되는 클래스 등 대부분의 코드가 포함되어 있습니다.

  • app/workers/gitlab/bitbucket_server_import: 이 디렉터리에는 Sidekiq 워커가 포함되어 있습니다.

임포트 진행 방식#

Bitbucket Server 프로젝트를 임포트하면 작업이 별도의 스테이지로 나뉘며, 각 스테이지는 실행되는 Sidekiq job의 집합으로 구성됩니다.

모든 스테이지 사이에는 Gitlab::BitbucketServerImport::AdvanceStageWorker라는 job이 예약되며, 현재 스테이지의 모든 작업이 완료되었는지 주기적으로 확인합니다. 모든 작업이 완료되면 이 job이 임포트 프로세스를 다음 스테이지로 진행시킵니다.

스테이지#

1. Stage::ImportRepositoryWorker#

이 워커는 리포지터리를 임포트하고 완료되면 다음 스테이지를 예약합니다.

2. Stage::ImportPullRequestsWorker#

이 워커는 모든 풀 리퀘스트를 임포트합니다. 풀 리퀘스트마다 Gitlab::BitbucketImport::ImportPullRequestWorker 워커에 대한 job이 예약됩니다.

Bitbucket Server는 열린 풀 리퀘스트에 대한 참조를 refs/heads/pull-requests에 추적하지만, 닫힌 요청과 머지된 요청은 stash-refs/pull-requests 하위의 숨겨진 내부 ref로 이동됩니다.

이 때문에 기본적으로 fetch되지 않습니다. 머지 리퀘스트에 커밋이 없어 diff가 비어 있는 상황을 방지하기 위해, 풀 리퀘스트를 임포트하기 전에 서버에서 영향을 받는 소스 및 타깃 커밋을 fetch합니다. fetch한 커밋은 ref로 저장하여 Git이 사용되지 않을 경우 제거하지 않도록 합니다. 소스 커밋은 #{commit}:refs/merge-requests/#{pull_request.iid}/head로 저장되고 타깃 커밋은 #{commit}:refs/keep-around/#{commit}으로 저장됩니다.

풀 리퀘스트를 생성할 때 작성자와 리뷰어에 대해 Bitbucket 사용자를 GitLab 사용자와 매핑해야 합니다. 일치하는 사용자가 발견되면 GitLab 사용자 ID가 24시간 동안 캐시되어 다시 검색할 필요가 없습니다.

3. Stage::ImportNotesWorker#

이 워커는 모든 머지 리퀘스트의 노트(댓글)를 임포트합니다.

각 머지 리퀘스트마다 Gitlab::BitbucketServerImport::ImportPullRequestNoteWorker 워커에 대한 job이 예약되며, 이 job은 머지 리퀘스트의 모든 독립 댓글, 인라인 댓글, 머지 이벤트, 승인 이벤트를 임포트합니다.

4. Stage::ImportLfsObjectsWorker#

모든 LFS 오브젝트에 대해 Gitlab::BitbucketServerImport::ImportLfsObjectsWorker job을 예약하여 소스 프로젝트에서 LFS 오브젝트를 임포트합니다.

5. Stage::FinishImportWorker#

이 워커는 임포트를 완료로 표시하는 등의 하우스키핑 작업을 수행하여 임포트 프로세스를 완료합니다.

사용자 기여 매핑#

Bitbucket Server 임포터는 사용자 기여 매핑을 지원합니다. 이를 통해 임포트가 완료된 후 실제 사용자가 할당될 때까지 임포트된 레코드를 플레이스홀더 사용자에게 귀속시킬 수 있습니다.

주요 클래스#

클래스 목적
BitbucketServerImport::UserFinder Bitbucket Server API 응답의 사용자 데이터를 GitLab 사용자 레코드로 매핑하기 위해 Import::SourceUserMapper를 호출하는 클래스

삭제된 사용자 처리#

Bitbucket Server 임포터는 삭제된 사용자에 대한 특별한 처리가 없습니다. 사용자 참조에 사용자 이름이 없는 경우 기여는 project.creator_id로 폴백됩니다.

풀 리퀘스트 멘션#

풀 리퀘스트 설명과 노트에는 사용자에 대한 멘션이 포함될 수 있습니다. 동일한 이메일을 가진 사용자가 GitLab에 존재하지 않는 경우, 잘못된 사용자가 태그될 수 있습니다.

이 문제를 해결하기 위해 Bitbucket 프로젝트에 접근할 수 있는 모든 사용자를 담은 캐시를 구축하고, 풀 리퀘스트 설명과 노트의 멘션을 변환합니다.

백오프 및 재시도#

속도 제한을 처리하기 위해 요청은 BitbucketServer::RetryWithDelay로 래핑됩니다. 이 래퍼는 응답이 속도 제한인지 확인하고, 응답 헤더에 지정된 지연 시간 이후에 한 번 재시도합니다.

Bitbucket Server 임포터 개발자 문서

GitLab v19.1
원문 보기
요약

임포트를 테스트하려면 로컬에서 실행 중인 Bitbucket Server 인스턴스가 필요합니다. 임포터의 코드베이스는 다음 디렉터리들로 구성되어 있습니다: lib/gitlab/bitbucket_server_import: 이 디렉터리에는 리소스 임포트에 사용되는 클래스 등 대부분의 코드가 포함되어 있습니다.

사전 요구 사항#

임포트를 테스트하려면 로컬에서 실행 중인 Bitbucket Server 인스턴스가 필요합니다. 로컬 인스턴스 실행 방법은 이 지침을 참조하세요.

코드 구조#

임포터의 코드베이스는 다음 디렉터리들로 구성되어 있습니다:

  • lib/gitlab/bitbucket_server_import: 이 디렉터리에는 리소스 임포트에 사용되는 클래스 등 대부분의 코드가 포함되어 있습니다.

  • app/workers/gitlab/bitbucket_server_import: 이 디렉터리에는 Sidekiq 워커가 포함되어 있습니다.

임포트 진행 방식#

Bitbucket Server 프로젝트를 임포트하면 작업이 별도의 스테이지로 나뉘며, 각 스테이지는 실행되는 Sidekiq job의 집합으로 구성됩니다.

모든 스테이지 사이에는 Gitlab::BitbucketServerImport::AdvanceStageWorker라는 job이 예약되며, 현재 스테이지의 모든 작업이 완료되었는지 주기적으로 확인합니다. 모든 작업이 완료되면 이 job이 임포트 프로세스를 다음 스테이지로 진행시킵니다.

스테이지#

1. Stage::ImportRepositoryWorker#

이 워커는 리포지터리를 임포트하고 완료되면 다음 스테이지를 예약합니다.

2. Stage::ImportPullRequestsWorker#

이 워커는 모든 풀 리퀘스트를 임포트합니다. 풀 리퀘스트마다 Gitlab::BitbucketImport::ImportPullRequestWorker 워커에 대한 job이 예약됩니다.

Bitbucket Server는 열린 풀 리퀘스트에 대한 참조를 refs/heads/pull-requests에 추적하지만, 닫힌 요청과 머지된 요청은 stash-refs/pull-requests 하위의 숨겨진 내부 ref로 이동됩니다.

이 때문에 기본적으로 fetch되지 않습니다. 머지 리퀘스트에 커밋이 없어 diff가 비어 있는 상황을 방지하기 위해, 풀 리퀘스트를 임포트하기 전에 서버에서 영향을 받는 소스 및 타깃 커밋을 fetch합니다. fetch한 커밋은 ref로 저장하여 Git이 사용되지 않을 경우 제거하지 않도록 합니다. 소스 커밋은 #{commit}:refs/merge-requests/#{pull_request.iid}/head로 저장되고 타깃 커밋은 #{commit}:refs/keep-around/#{commit}으로 저장됩니다.

풀 리퀘스트를 생성할 때 작성자와 리뷰어에 대해 Bitbucket 사용자를 GitLab 사용자와 매핑해야 합니다. 일치하는 사용자가 발견되면 GitLab 사용자 ID가 24시간 동안 캐시되어 다시 검색할 필요가 없습니다.

3. Stage::ImportNotesWorker#

이 워커는 모든 머지 리퀘스트의 노트(댓글)를 임포트합니다.

각 머지 리퀘스트마다 Gitlab::BitbucketServerImport::ImportPullRequestNoteWorker 워커에 대한 job이 예약되며, 이 job은 머지 리퀘스트의 모든 독립 댓글, 인라인 댓글, 머지 이벤트, 승인 이벤트를 임포트합니다.

4. Stage::ImportLfsObjectsWorker#

모든 LFS 오브젝트에 대해 Gitlab::BitbucketServerImport::ImportLfsObjectsWorker job을 예약하여 소스 프로젝트에서 LFS 오브젝트를 임포트합니다.

5. Stage::FinishImportWorker#

이 워커는 임포트를 완료로 표시하는 등의 하우스키핑 작업을 수행하여 임포트 프로세스를 완료합니다.

사용자 기여 매핑#

Bitbucket Server 임포터는 사용자 기여 매핑을 지원합니다. 이를 통해 임포트가 완료된 후 실제 사용자가 할당될 때까지 임포트된 레코드를 플레이스홀더 사용자에게 귀속시킬 수 있습니다.

주요 클래스#

클래스 목적
BitbucketServerImport::UserFinder Bitbucket Server API 응답의 사용자 데이터를 GitLab 사용자 레코드로 매핑하기 위해 Import::SourceUserMapper를 호출하는 클래스

삭제된 사용자 처리#

Bitbucket Server 임포터는 삭제된 사용자에 대한 특별한 처리가 없습니다. 사용자 참조에 사용자 이름이 없는 경우 기여는 project.creator_id로 폴백됩니다.

풀 리퀘스트 멘션#

풀 리퀘스트 설명과 노트에는 사용자에 대한 멘션이 포함될 수 있습니다. 동일한 이메일을 가진 사용자가 GitLab에 존재하지 않는 경우, 잘못된 사용자가 태그될 수 있습니다.

이 문제를 해결하기 위해 Bitbucket 프로젝트에 접근할 수 있는 모든 사용자를 담은 캐시를 구축하고, 풀 리퀘스트 설명과 노트의 멘션을 변환합니다.

백오프 및 재시도#

속도 제한을 처리하기 위해 요청은 BitbucketServer::RetryWithDelay로 래핑됩니다. 이 래퍼는 응답이 속도 제한인지 확인하고, 응답 헤더에 지정된 지연 시간 이후에 한 번 재시도합니다.