히스토리

• GitLab 17.4에서 importer_user_mapping 및 bulk_import_importer_user_mapping이라는 플래그를 사용하는 direct transfer용으로 도입됨. 기본적으로 비활성화됨.

• GitLab 17.6에서 importer_user_mapping 및 gitea_user_mapping이라는 플래그를 사용하는 Gitea용과, importer_user_mapping 및 github_user_mapping이라는 플래그를 사용하는 GitHub용으로 도입됨. 기본적으로 비활성화됨.

• GitLab 17.7에서 importer_user_mapping 및 bitbucket_server_user_mapping이라는 플래그를 사용하는 Bitbucket Server용으로 도입됨. 기본적으로 비활성화됨.

• GitLab 17.7에서 direct transfer용으로 GitLab.com 및 GitLab Self-Managed에서 활성화됨.

• GitLab 17.7에서 Bitbucket Server, Gitea, GitHub용으로 GitLab.com에서 활성화됨.

• GitLab 17.8에서 Bitbucket Server, Gitea, GitHub용으로 GitLab Self-Managed에서 활성화됨.

• 개인 네임스페이스로 가져올 때 개인 네임스페이스 소유자에게 기여를 재할당하는 기능이 GitLab 18.3에서 user_mapping_to_personal_namespace_owner라는 플래그를 사용하여 도입됨. 기본적으로 비활성화됨.

• GitLab 18.4에서 direct transfer용으로 일반적으로 사용 가능해짐. bulk_import_importer_user_mapping 기능 플래그가 제거됨.

• 서비스 계정, 프로젝트 봇, 그룹 봇에 기여를 재할당하는 기능이 GitLab 18.5에서 user_mapping_service_account_and_bots라는 플래그를 사용하여 도입됨. 기본적으로 활성화됨.

• GitLab 18.6에서 Gitea용으로 일반적으로 사용 가능해짐. gitea_user_mapping 기능 플래그가 제거됨.

• 개인 네임스페이스로 가져올 때 개인 네임스페이스 소유자에게 기여를 재할당하는 기능이 GitLab 18.6에서 일반적으로 사용 가능해짐. user_mapping_to_personal_namespace_owner 기능 플래그가 제거됨.

• github_user_mapping 기능 플래그가 GitLab 18.8에서 제거됨.

• user_mapping_service_account_and_bots 기능 플래그가 GitLab 18.10에서 제거됨.

마이그레이션 후 매핑을 사용하면, 소스 인스턴스의 사용자 기여 및 멤버십이 처음에는 대상 인스턴스의 실제 사용자가 아닌 플레이스홀더 사용자에게 할당됩니다.

실제 사용자에게 할당을 나중에 할 수 있으므로, 가져오기를 검토하고 기여를 올바른 사용자에게 재할당할 시간이 생깁니다. 이 프로세스는 매핑 과정에 대한 제어권을 유지하면서 정확한 기여 귀속을 보장합니다.

마이그레이션 후 사용자 기여 및 멤버십 매핑은 다음 마이그레이션에 대해 기본적으로 사용 가능합니다:

• direct transfer를 사용하는 GitLab

• GitHub

• Bitbucket Server

• Gitea

프로젝트를 개인 네임스페이스로 가져올 때는, 사용자 기여 매핑과 멤버십 매핑이 지원되지 않으며 모든 기여는 개인 네임스페이스 소유자에게 할당됩니다. 이러한 기여는 재할당할 수 없습니다.

사전 요구 사항#

• 사용자 제한에 따라 사용자 수를 계획하세요.

• GitLab.com으로 가져오는 경우, 유료 네임스페이스를 설정하세요.

• GitLab.com으로 가져오고 GitLab.com 그룹용 SAML SSO를 사용하는 경우, 모든 사용자가 SAML ID를 GitLab.com 계정에 연결했는지 확인하세요.

마이그레이션 후 매핑 워크플로#

마이그레이션 후 매핑을 사용하면, GitLab은 가져온 모든 멤버십과 기여를 플레이스홀더 사용자에게 매핑합니다. 대상 인스턴스에 동일한 이메일 주소를 가진 사용자가 있더라도 플레이스홀더 사용자는 대상 인스턴스에 생성됩니다. 대상 인스턴스에서 기여를 재할당하기 전까지, 모든 기여는 플레이스홀더 사용자와 연결됩니다.

가져오기가 완료되고 결과를 검토한 후, 다음과 같이 매핑을 업데이트할 수 있습니다:

• 대상 인스턴스의 기존 사용자에게 멤버십과 기여를 재할당하세요. 소스 및 대상 인스턴스에서 이메일 주소가 다른 사용자의 멤버십과 기여를 매핑할 수 있습니다.

• 대상 인스턴스에 새 사용자를 만들고 멤버십과 기여를 재할당하세요.

기록 보존을 위해 특정 기여를 플레이스홀더 사용자에게 계속 할당할 수도 있습니다.

대상 인스턴스의 사용자에게 기여를 재할당하면, 해당 사용자는 다음 중 하나를 선택할 수 있습니다:

• 재할당을 수락합니다. 재할당 프로세스는 몇 분 정도 걸릴 수 있습니다. 대상 인스턴스의 동일한 최상위 그룹 또는 하위 그룹에 동일한 소스 인스턴스에서 이후 가져오기를 진행하면, 기여는 자동으로 해당 사용자에게 매핑됩니다.

• 재할당을 거부합니다.

엔터프라이즈 사용자#

히스토리

• GitLab 18.0에서 도입됨.

최상위 그룹에 엔터프라이즈 사용자가 한 명 이상 있는 경우, 조직 내 엔터프라이즈 사용자에게만 기여를 재할당할 수 있습니다.

이를 통해 조직 외부의 사용자에게 실수로 재할당하는 것을 방지할 수 있습니다.

삭제된 사용자#

소스 인스턴스에서 현재 삭제된 사용자가 작성한 기여는 대상 인스턴스에서 고스트 사용자에게 매핑됩니다. 단, 다음 경우는 예외입니다:

• 소스 인스턴스에서 해당 기여가 삭제된 사용자로부터 올바르게 분리되지 않은 경우.

• Bitbucket Server에서 마이그레이션하는 경우.

플레이스홀더 사용자#

기여 및 멤버십 매핑을 사용하면, 대상 인스턴스의 사용자에게 기여와 멤버십을 즉시 할당하지 않습니다. 대신, 가져온 기여나 멤버십이 있는 활성, 비활성 또는 봇 사용자에 대해 플레이스홀더 사용자가 생성됩니다.

기여와 멤버십은 처음에 이 플레이스홀더 사용자에게 할당되며, 가져오기 후 대상 인스턴스의 기존 사용자에게 재할당할 수 있습니다.

재할당되기 전까지 기여는 플레이스홀더와 연결됩니다. 플레이스홀더 멤버십은 멤버 목록에 표시되지 않습니다.

플레이스홀더 사용자는 라이선스 제한에 포함되지 않습니다.

예외#

다음 시나리오에서는 플레이스홀더 사용자가 생성되지 않습니다:

• 삭제된 사용자의 기여가 있는 Gitea 프로젝트를 가져오는 경우. 이러한 사용자의 기여는 프로젝트를 가져온 사용자에게 매핑됩니다.

• 플레이스홀더 사용자 제한을 초과한 경우. 새 사용자의 기여는 가져오기 사용자에게 매핑됩니다.

플레이스홀더 사용자 속성#

플레이스홀더 사용자는 일반 사용자와 다르며 다음을 할 수 없습니다:

• 로그인.

• 어떤 작업도 수행. 예를 들어, 파이프라인 실행.

• 이슈 및 머지 리퀘스트의 담당자 또는 검토자 제안에 표시.

• 프로젝트 및 그룹의 멤버가 됨.

소스 인스턴스의 사용자와 연결을 유지하기 위해, 플레이스홀더 사용자에는 다음이 있습니다:

• 새 플레이스홀더 사용자가 필요한지 가져오기 프로세스가 결정하는 데 사용하는 고유 식별자(source_user_id).

• 소스 호스트명 또는 도메인(source_hostname).

• 기여 재할당을 도와주는 소스 사용자 이름(source_name).

• 기여 재할당 시 그룹 Owner를 지원하는 소스 사용자 사용자명(source_username).

• 어떤 가져오기 도구가 플레이스홀더를 생성했는지 구분하는 가져오기 유형(import_type).

• 마이그레이션 추적을 위한 소스 사용자 생성 시간의 타임스탬프(created_at), 현지 시간으로 표시 (GitLab 17.10에서 도입됨).

기록 보존을 위해, 플레이스홀더 사용자의 이름과 사용자명은 소스 사용자의 이름과 사용자명에서 파생됩니다:

• 플레이스홀더 사용자의 이름은 Placeholder <source user name>입니다.

• 플레이스홀더 사용자의 사용자명은 %{source_username}_placeholder_user_%{incremental_number}입니다.

플레이스홀더 사용자 보기#

사전 요구 사항:

• 해당 그룹에 대한 Owner 권한이 있어야 합니다.

플레이스홀더 사용자는 그룹 또는 프로젝트를 가져오는 동안 대상 인스턴스에 생성됩니다. 최상위 그룹 및 해당 하위 그룹으로 가져오는 동안 생성된 플레이스홀더 사용자를 보려면:

• 상단 바에서 Search or go to를 선택하고 그룹을 찾으세요. 이 그룹은 최상위 레벨이어야 합니다.

• 왼쪽 사이드바에서 Manage > Members를 선택하세요.

• Placeholders 탭을 선택하세요.

플레이스홀더 사용자 필터링#

DETAILS: Offering: GitLab Self-Managed, GitLab Dedicated

히스토리

• GitLab 17.11에서 도입됨.

사전 요구 사항:

• 인스턴스에 대한 관리자 액세스 권한이 있어야 합니다.

플레이스홀더 사용자는 그룹 또는 프로젝트를 가져오는 동안 대상 인스턴스에 생성됩니다. 전체 인스턴스의 가져오기 중 생성된 플레이스홀더 사용자를 필터링하려면:

• 오른쪽 상단에서 Admin을 선택하세요.

• 왼쪽 사이드바에서 Overview > Users를 선택하세요.

• 검색 상자에서 type으로 사용자를 필터링하세요.

플레이스홀더 사용자 생성#

플레이스홀더 사용자는 가져오기 소스 및 최상위 그룹별로 생성됩니다:

• 대상 인스턴스의 동일한 최상위 그룹에 동일한 프로젝트를 두 번 가져오는 경우, 두 번째 가져오기는 첫 번째 가져오기와 동일한 플레이스홀더 사용자를 사용합니다.

• 동일한 프로젝트를 두 번 가져오지만 대상 인스턴스의 다른 최상위 그룹으로 가져오는 경우, 두 번째 가져오기는 해당 최상위 그룹 아래에 새 플레이스홀더 사용자를 생성합니다.

사용자가 재할당을 수락하면, 동일한 소스 인스턴스에서 대상 인스턴스의 동일한 최상위 그룹 또는 하위 그룹으로의 이후 가져오기는 플레이스홀더 사용자를 생성하지 않습니다. 대신, 기여는 자동으로 해당 사용자에게 매핑됩니다.

플레이스홀더 사용자 삭제#

히스토리

• GitLab 18.0에서 도입됨.

플레이스홀더 사용자가 포함된 최상위 그룹을 삭제하면, 해당 사용자는 자동으로 제거 예약됩니다. 이 프로세스는 완료하는 데 시간이 걸릴 수 있습니다. 그러나 플레이스홀더 사용자가 다른 프로젝트나 그룹과도 연결된 경우에는 시스템에 남아 있습니다.

플레이스홀더 사용자 제한#

GitLab.com으로 가져오는 경우, 플레이스홀더 사용자는 대상 인스턴스의 최상위 그룹별로 제한됩니다. 제한은 플랜 및 시트 수에 따라 다릅니다. 플레이스홀더 사용자는 라이선스 제한에 포함되지 않습니다.

GitLab Self-Managed 및 GitLab Dedicated의 경우, 기본적으로 플레이스홀더 제한이 적용되지 않습니다. GitLab 관리자는 인스턴스에서 플레이스홀더 제한을 설정할 수 있습니다.

현재 플레이스홀더 사용자 사용량 및 제한을 보려면:

• 상단 바에서 Search or go to를 선택하고 그룹을 찾으세요. 이 그룹은 최상위 레벨이어야 합니다.

• Settings > Usage quotas를 선택하세요.

• Import 탭을 선택하세요.

사전에 필요한 플레이스홀더 사용자 수를 결정할 수 없습니다.

플레이스홀더 사용자 제한에 도달하면, 모든 기여는 Import User라는 단일 비기능 사용자에게 할당됩니다. Import User에게 할당된 기여는 중복 제거될 수 있으며, 일부 기여는 가져오기 중에 생성되지 않을 수 있습니다. 예를 들어, 머지 리퀘스트 승인자의 여러 승인이 Import User에게 할당된 경우, 첫 번째 승인만 생성되고 나머지는 무시됩니다. 중복 제거될 수 있는 기여는 다음과 같습니다:

• 승인 규칙

• 이모지 반응

• 이슈 담당자

• 멤버십

• 머지 리퀘스트 승인, 담당자 및 검토자

• 푸시, 머지 리퀘스트 및 배포 액세스 수준

모든 변경 사항은 시스템 노트를 생성하며, 이는 플레이스홀더 사용자 제한의 영향을 받지 않습니다.

대체 매핑 방법#

마이그레이션 후 매핑의 대안으로 마이그레이션 중에 매핑하는 방법이 있습니다. 이 방법은 권장되지 않으며, 발견된 문제는 수정될 가능성이 낮습니다.

대체 매핑 방법의 특징:

• GitLab Self-Managed로의 마이그레이션에만 사용 가능합니다.

• 해당 *_user_mapping 기능 플래그 비활성화 등 마이그레이션 전 일부 준비가 필요합니다.

• 다음에서의 마이그레이션에 사용 가능합니다:

GitHub.

• Bitbucket Server.

• Gitea (GitLab 18.5 이하).

자세한 내용은 각 가져오기 도구의 대체 매핑 방법 문서를 참조하세요.