테스트 프로젝트 임포트

요약

테스트를 위해 qa-perf-testing이라는 그룹 아래에 자체 GitLab CE 프로젝트(이 경우 gitlabhq라는 이름)를 임포트할 수 있습니다. 프로젝트를 GitLab 환경에 임포트하는 방법은 여러 가지가 있습니다.

테스트를 위해 qa-perf-testing이라는 그룹 아래에 자체 GitLab CE 프로젝트(이 경우 gitlabhq라는 이름)를 임포트할 수 있습니다. 테스트에 사용할 수 있는 프로젝트 tar 파일은 performance-data 프로젝트에서 찾을 수 있습니다. 필요한 경우 다른 프로젝트를 사용할 수도 있습니다.

프로젝트를 GitLab 환경에 임포트하는 방법은 여러 가지가 있습니다. 아래에서는 권장 그룹 qa-perf-testing과 프로젝트 gitlabhq를 설정하는 것을 가정하여 각 방법을 자세히 설명합니다.

프로젝트 임포트#

테스트 프로젝트를 임포트하려면 다음 방법 중 하나를 사용하세요.

UI를 사용하여 임포트#

첫 번째 옵션은 GitLab UI를 사용하여 프로젝트 tar 파일을 임포트하는 것입니다:

qa-perf-testing 그룹을 생성합니다.
GitLab FOSS 프로젝트 tar 파일을 해당 그룹에 임포트합니다.

프로젝트가 완전히 임포트되는 데 최대 15분이 소요될 수 있습니다. 현재 상태를 확인하려면 프로젝트의 메인 페이지로 이동하세요.

이 방법은 모든 오류(GITALY_DISABLE_REQUEST_LIMITS와 관련된 오류 포함)를 자동으로 무시하며, GitLab 사용자들이 사용합니다. 개발 및 테스트의 경우, 아래의 다른 방법들을 확인하세요.

import-project 스크립트를 사용하여 임포트#

performance 프로젝트에는 터미널에서 API를 통해 GitLab 환경에 프로젝트 tar 파일을 임포트할 수 있는 편리한 스크립트 bin/import-project가 제공됩니다.

아직 설정하지 않은 경우, 스크립트를 사용하기 위해 몇 가지 준비가 필요합니다:

먼저, 머신에 Ruby와 Ruby Bundler가 없으면 설치합니다.
다음으로, bundle install 명령으로 Bundler를 통해 필요한 Ruby Gem을 설치합니다.

bin/import-project 사용 방법에 대한 자세한 내용은 다음을 실행하세요:

bin/import-project --help

프로젝트가 완전히 임포트되는 데 최대 15분이 소요될 수 있습니다. 스크립트는 주기적으로 상태를 확인하고 임포트가 완료되면 종료됩니다.

GitHub를 사용하여 임포트#

GitHub를 통해 프로젝트를 임포트하는 옵션도 있습니다:

qa-perf-testing 그룹을 생성합니다.
UI를 통해 GitHub에 미러링된 GitLab FOSS 리포지터리를 그룹에 임포트합니다.

이 방법은 다른 방법보다 임포트에 더 오랜 시간이 걸리며, 여러 요소에 따라 달라집니다. 다른 방법을 사용하는 것을 권장합니다.

GitHub Enterprise(GHE)에서 GitLab으로의 임포트를 테스트하려면 GHE 인스턴스가 필요합니다. GitHub Enterprise Server 평가판을 요청하고 Google Cloud Platform에 설치할 수 있습니다.

GitLab 팀 멤버는 이 목적으로 Sandbox Cloud Realm을 사용할 수 있습니다.
그 외의 사용자는 Google Cloud Platforms 무료 평가판을 요청할 수 있습니다.

Rake task를 사용하여 임포트#

Rake task를 사용하여 테스트 프로젝트를 임포트하려면 대형 프로젝트 임포트를 참조하세요.

Rails 콘솔을 사용하여 임포트#

마지막 옵션은 Rails 콘솔을 사용하여 프로젝트를 임포트하는 것입니다:

Ruby on Rails 콘솔을 시작합니다:

# Omnibus GitLab
gitlab-rails console

# For installations from source
sudo -u git -H bundle exec rails console -e production

프로젝트를 생성하고 Project::TreeRestorer를 실행합니다:

shared_class = Struct.new(:export_path) do
  def error(message)
    raise message
  end
end

user = User.first

shared = shared_class.new(path)

project = Projects::CreateService.new(user, { name: name, namespace: user.namespace }).execute
begin
  #Enable Request store
  RequestStore.begin!
  Gitlab::ImportExport::Project::TreeRestorer.new(user: user, shared: shared, project: project).restore
ensure
  RequestStore.end!
  RequestStore.clear!
end

리포지터리도 필요한 경우 다음을 사용하여 복원할 수 있습니다:

repo_path = File.join(shared.export_path, Gitlab::ImportExport.project_bundle_filename)

Gitlab::ImportExport::RepoRestorer.new(path_to_bundle: repo_path,
                                       shared: shared,
                                       importable: project).restore

모든 임포트 실패 사항은 import_failures 데이터 테이블에 저장됩니다.

프로젝트 임포트가 문제 없이 완료되었는지 확인하려면 다음을 확인하세요:

project.import_failures.all

성능 테스트#

성능 테스트를 위해 다음을 수행해야 합니다:

상당히 큰 프로젝트를 임포트합니다. gitlabhq가 좋은 예시입니다.
Project::TreeRestorer의 실행 시간을 측정합니다.
복원 중 실행된 SQL 쿼리 수를 계산합니다.
발생하는 GC 사이클 수를 관찰합니다.

다음 스니펫을 사용할 수 있습니다: https://gitlab.com/gitlab-org/gitlab/snippets/1924954(로그인 필요). 이 스니펫은 프로젝트를 복원하고 Project::TreeRestorer의 실행 시간, SQL 쿼리 수, GC 사이클 발생 수를 측정합니다.

gdk/gitlab 디렉터리에서 다음과 같이 스크립트를 실행할 수 있습니다:

bundle exec rails r  /path_to_script/script.rb project_name /path_to_extracted_project request_store_enabled

액세스 토큰 설정#

많은 테스트에서는 수많은 엔드포인트가 인증을 필요로 하기 때문에 GitLab 개인 액세스 토큰도 요구됩니다.

GitLab 문서에서 이 토큰을 생성하는 방법을 자세히 설명합니다. 테스트에서는 토큰이 관리자에 의해 생성되어야 하며 API 및 read_repository 권한이 있어야 합니다.

각 테스트 유형에서 액세스 토큰을 사용하는 방법에 대한 자세한 내용은 해당 문서에서 확인할 수 있습니다.