InfoGrab DocsInfoGrab Docs

개발자를 위한 Rake 태스크

요약

Rake 태스크는 개발자 및 GitLab에 기여하는 분들을 위해 제공됩니다. 데이터베이스 사용자에게 고급 권한이 없는 경우, 이 명령을 실행하기 전에 데이터베이스를 수동으로 생성해야 합니다. setup 태스크는 gitlab:setup의 별칭입니다.

Rake 태스크는 개발자 및 GitLab에 기여하는 분들을 위해 제공됩니다.

개발자 시드로 데이터베이스 설정#

데이터베이스 사용자에게 고급 권한이 없는 경우, 이 명령을 실행하기 전에 데이터베이스를 수동으로 생성해야 합니다.

bundle exec rake setup

setup 태스크는 gitlab:setup의 별칭입니다. 이 태스크는 db:reset을 호출하여 데이터베이스를 생성하고, db:seed_fu를 호출하여 데이터베이스에 시드 데이터를 삽입합니다. db:setup은 db:seed를 호출하지만 아무런 동작도 하지 않습니다.

환경 변수#

MASS_INSERT: 수백만 개의 사용자(200만), 프로젝트(500만) 및 관련 데이터를 생성합니다. 개발 중 느린 쿼리를 찾기 위해 이 옵션과 함께 시드를 실행하는 것이 강력히 권장됩니다. 프로세스를 완료하는 데 최대 20분이 추가로 소요될 수 있습니다.

Rails 모델 대량 삽입도 참고하세요.

LARGE_PROJECTS: 미리 정의된 URL 집합에서 (가져오기를 통해) 대형 프로젝트를 생성합니다.

시드 데이터#

모든 프로젝트 또는 특정 프로젝트에 이슈 시드 삽입#

gitlab:seed:issues 태스크를 사용하여 모든 프로젝트 또는 특정 프로젝트에 이슈 시드 데이터를 삽입할 수 있습니다:

# 모든 프로젝트
bin/rake gitlab:seed:issues

# 특정 프로젝트
bin/rake "gitlab:seed:issues[group-path/project-path]"

기본적으로 각 프로젝트에 대해 최근 5주 동안 주당 평균 2개의 이슈를 시드합니다.

Insights 차트를 위한 이슈 시드 삽입#

gitlab:seed:insights:issues 태스크를 사용하여 Insights 차트와 함께 사용하기 위한 이슈 시드 데이터를 삽입할 수 있습니다:

# 모든 프로젝트
bin/rake gitlab:seed:insights:issues

# 특정 프로젝트
bin/rake "gitlab:seed:insights:issues[group-path/project-path]"

기본적으로 각 프로젝트에 대해 최근 52주 동안 주당 평균 10개의 이슈를 시드합니다. 모든 이슈에는 팀, 유형, 심각도, 우선순위 라벨이 무작위로 지정됩니다.

하위 그룹이 포함된 그룹 시드 삽입#

gitlab:seed:group_seed 태스크를 사용하여 마일스톤/프로젝트가 포함된 하위 그룹이 있는 그룹에 시드 데이터를 삽입할 수 있습니다:

bin/rake "gitlab:seed:group_seed[subgroup_depth, username, organization_path]"

GitLab 인스턴스에 에픽 기능이 있는 경우 그룹에 에픽도 함께 시드됩니다.

러너 플릿 테스트 환경 시드 삽입#

gitlab:seed:runner_fleet 태스크를 사용하여 러너 및 파이프라인이 포함된 하위 그룹과 프로젝트가 있는 그룹으로 구성된 전체 러너 플릿을 시드합니다:

bin/rake "gitlab:seed:runner_fleet[username, registration_prefix, runner_count, job_count]"

기본적으로 Rake 태스크는 root 사용자 이름을 사용하여 40개의 러너와 400개의 job을 생성합니다.

%%{init: { "fontFamily": "GitLab Sans" }}%% graph TD accTitle: Seeding a runner fleet test environment accDescr: Diagram showing how the runner seed rake task seeds a full runner fleet with groups, subgroups, and projects with runners and pipelines

G1[Top-level group 1] --> G11
G2[Top-level group 2] --> G21
G11[Group 1.1] --> G111
G11[Group 1.1] --> G112
G111[Group 1.1.1] --> P1111
G112[Group 1.1.2] --> P1121
G21[Group 2.1] --> P211

P1111[Project 1.1.1.1<br><i>70% of jobs, sent to first 5 runners</i>]
P1121[Project 1.1.2.1<br><i>15% of jobs, sent to first 5 runners</i>]
P211[Project 2.1.1<br><i>15% of jobs, sent to first 5 runners</i>]

IR1[Instance runner]
P1111R1[Shared runner]
P1111R[Project 1.1.1.1 runners<br>20% total runners]
P1121R[Project 1.1.2.1 runners<br>49% total runners]
G111R[Group 1.1.1 runners<br>30% total runners<br><i>remaining jobs</i>]
G21R[Group 2.1 runners<br>1% total runners]

P1111 --> P1111R1
P1111 --> G111R
P1111 --> IR1
P1111 --> P1111R
P1121 --> P1111R1
P1121 --> IR1
P1121 --> P1121R
P211 --> P1111R1
P211 --> G21R
P211 --> IR1

classDef groups stroke-width:3px;
classDef projects stroke-width:2px;
class G1,G2,G11,G111,G112,G21 groups
class P1111,P1121,P211 projects

모니터링 대시보드의 커스텀 메트릭 시드 삽입#

모니터링 대시보드에서는 다양한 유형의 메트릭을 지원합니다.

이러한 메트릭을 가져오려면 다음을 실행합니다:

bundle exec rake 'gitlab:seed:development_metrics[your_project_id]'

취약점이 포함된 프로젝트 시드 삽입#

보안 취약점이 있는 프로젝트에 시드 데이터를 삽입할 수 있습니다.

# 모든 프로젝트에 시드 삽입
bin/rake 'gitlab:seed:vulnerabilities'

# 특정 프로젝트에 시드 삽입
bin/rake 'gitlab:seed:vulnerabilities[group-path/project-path]'

환경이 포함된 프로젝트 시드 삽입#

환경이 있는 프로젝트에 시드 데이터를 삽입할 수 있습니다.

기본적으로 각각 ENV_ 접두사를 가진 10개의 환경이 생성됩니다. 이 명령을 실행하려면 project_path만 필요합니다.

bundle exec rake "gitlab:seed:project_environments[project_path, seed_count, prefix]"

# 예시
bundle exec rake "gitlab:seed:project_environments[flightjs/Flight]"
bundle exec rake "gitlab:seed:project_environments[flightjs/Flight, 25, FLIGHT_ENV_]"

의존성이 포함된 그룹 시드 삽입#

bundle exec rake gitlab:seed:dependencies

CI 변수 시드 삽입#

CI 변수가 있는 프로젝트, 그룹, 또는 인스턴스에 시드 데이터를 삽입할 수 있습니다.

기본적으로 각 명령은 10개의 CI 변수를 생성합니다. 변수 이름에는 기본 접두사가 붙습니다(프로젝트 수준 변수는 VAR_, 그룹 수준 변수는 GROUP_VAR_, 인스턴스 수준 변수는 INSTANCE_VAR_).

인스턴스 수준 변수에는 환경 범위가 없습니다. 프로젝트 수준 및 그룹 수준 변수는 environment_scope가 지정되지 않은 경우 기본 "*" 환경 범위를 사용합니다. environment_scope가 "unique"로 설정되면 각 변수는 고유한 환경으로 생성됩니다.

# 프로젝트 수준 CI 변수로 프로젝트에 시드 삽입
# 이 명령을 실행하려면 `project_path`만 필요합니다.
bundle exec rake "gitlab:seed:ci_variables_project[project_path, seed_count, environment_scope, prefix]"

# 그룹 수준 CI 변수로 그룹에 시드 삽입
# 이 명령을 실행하려면 `group_name`만 필요합니다.
bundle exec rake "gitlab:seed:ci_variables_group[group_name, seed_count, environment_scope, prefix]"

# 인스턴스 수준 CI 변수로 인스턴스에 시드 삽입
bundle exec rake "gitlab:seed:ci_variables_instance[seed_count, prefix]"

# 예시
bundle exec rake "gitlab:seed:ci_variables_project[flightjs/Flight]"
bundle exec rake "gitlab:seed:ci_variables_project[flightjs/Flight, 25, staging]"
bundle exec rake "gitlab:seed:ci_variables_project[flightjs/Flight, 25, unique, CI_VAR_]"

bundle exec rake "gitlab:seed:ci_variables_group[group_name]"
bundle exec rake "gitlab:seed:ci_variables_group[group_name, 25, staging]"
bundle exec rake "gitlab:seed:ci_variables_group[group_name, 25, unique, CI_VAR_]"

bundle exec rake "gitlab:seed:ci_variables_instance"
bundle exec rake "gitlab:seed:ci_variables_instance[25, CI_VAR_]"

머지 트레인 개발을 위한 프로젝트 시드 삽입#

머지 트레인이 구성된 프로젝트와 20개의 머지 리퀘스트(각각 커밋 3개 포함)를 시드합니다. 명령:

rake gitlab:seed:merge_trains:project

자동화#

현재 데이터베이스를 완전히 초기화하고 시드 데이터를 다시 채우려는 경우, FORCE 환경 변수를 yes로 설정할 수 있습니다:

FORCE=yes bundle exec rake setup

이렇게 하면 동작 확인/안전 검사가 건너뛰어져 yes를 수동으로 입력하지 않아도 됩니다.

stdout 출력 무시#

스크립트가 많은 정보를 출력하므로 터미널이 느려질 수 있으며, 파일로 리디렉션하면 20G 이상의 로그가 생성될 수 있습니다. 출력이 필요 없는 경우, /dev/null로 리디렉션하면 됩니다:

echo 'yes' | bundle exec rake setup > /dev/null

stdout에서 질문을 볼 수 없으므로, 실행을 계속하려면 echo 'yes'를 사용하는 것이 좋습니다. 오류는 여전히 stderr에 출력되므로 오류를 놓칠 걱정은 없습니다.

추가 프로젝트 시드 옵션#

프로젝트 시드 방식을 변경하기 위해 전달할 수 있는 환경 플래그가 몇 가지 있습니다.

  • SIZE: 기본값은 8, 최대: 32. 생성할 프로젝트 수입니다.

  • LARGE_PROJECTS: 기본값은 false. 설정하면 테스트를 돕기 위해 6개의 대형 프로젝트를 클론합니다.

  • FORK: 기본값은 false. true로 설정하면 torvalds/linux를 5번 포크합니다. 대신 포크할 기존 프로젝트의 full_path로도 설정할 수 있습니다.

테스트 실행#

테스트를 실행하려면 다음 명령을 사용할 수 있습니다:

  • bin/rake spec: RSpec 스위트 실행

  • bin/rake spec:unit: 단위 테스트만 실행

  • bin/rake spec:integration: 통합 테스트만 실행

  • bin/rake spec:system: 시스템 테스트만 실행

bin/rake spec은 완료하는 데 상당한 시간이 걸립니다. 로컬에서 전체 테스트 스위트를 실행하는 대신, 변경 사항과 관련된 단일 테스트 또는 디렉터리를 실행하면 시간을 절약할 수 있습니다. 머지 리퀘스트를 제출하면 CI가 전체 테스트 스위트를 대신 실행해줍니다. 머지 리퀘스트에서 CI 상태가 녹색이면 전체 테스트 스위트가 통과된 것입니다.

rspec .은 실행할 수 없습니다. 이 명령은 /tmp에 있는 파일을 포함하여 찾을 수 있는 모든 _spec.rb 파일을 실행하려 합니다.

spec:unit, spec:integration, spec:system 태스크에 RSpec 커맨드라인 옵션을 전달할 수 있습니다. 예를 들어, bin/rake "spec:unit[--tag ~geo --dry-run]".

RSpec 테스트에서 단일 테스트 파일을 실행하려면 다음을 실행합니다:

bin/rspec spec/controllers/commit_controller_spec.rb

하나의 디렉터리 내 여러 테스트를 실행하려면:

  • bin/rspec spec/requests/api/: API만 테스트하려는 경우 RSpec 테스트 실행

머지 리퀘스트 파이프라인에서 실패한 RSpec 테스트를 로컬에서 실행#

머지 리퀘스트 파이프라인이 RSpec 테스트 실패로 실패한 경우, 다음 Rake 태스크를 사용하여 실패한 모든 테스트를 로컬에서 실행할 수 있습니다:

bin/rake spec:merge_request_rspec_failure

이 Rake 태스크에는 몇 가지 주의사항이 있습니다:

  • 로컬 머신에서 머지 리퀘스트의 소스 브랜치와 동일한 브랜치에 있어야 합니다.

  • 파이프라인이 완료되어 있어야 합니다.

  • 테스트 보고서가 파싱될 때까지 기다렸다가 다시 시도해야 할 수도 있습니다.

이 Rake 태스크는 처음 요청될 때만 파싱되는 단위 테스트 보고서 기능에 의존합니다.

테스트, Rake 태스크, 마이그레이션 속도 향상#

Spring은 Rails 애플리케이션 프리로더입니다. 애플리케이션을 백그라운드에서 계속 실행 상태로 유지하여 테스트, Rake 태스크, 마이그레이션을 실행할 때마다 부팅할 필요가 없도록 개발 속도를 높여줍니다.

사용하려면 ENABLE_SPRING 환경 변수를 1로 export해야 합니다:

export ENABLE_SPRING=1

또는 각 spec 실행 시 다음을 사용할 수 있습니다:

bundle exec spring rspec some_spec.rb

RuboCop 태스크#

초기 RuboCop TODO 목록 생성#

초기 목록을 생성하는 한 가지 방법은 rubocop:todo:generate Rake 태스크를 실행하는 것입니다:

bundle exec rake rubocop:todo:generate

특정 RuboCop 규칙에 대한 TODO 목록을 생성하려면, Rake 태스크에 쉼표로 구분된 인수로 전달합니다:

bundle exec rake 'rubocop:todo:generate[Gitlab/NamespacedClass,Lint/Syntax]'
bundle exec rake rubocop:todo:generate\[Gitlab/NamespacedClass,Lint/Syntax\]

일부 셸에서는 괄호를 이스케이프하거나 따옴표로 묶어야 합니다.

이후 진행 방법은 RuboCop 예외 해결을 참고하세요.

"그레이스풀 모드"로 RuboCop 실행#

RuboCop을 "그레이스풀 모드"로 실행할 수 있습니다. 이 모드에서는 "유예 기간"이 활성화된(Details: grace period 사용) 모든 활성화된 cop 규칙이 무음 처리됩니다.

실행 방법:

bundle exec rake 'rubocop:check:graceful'
bundle exec rake 'rubocop:check:graceful[Gitlab/NamespacedClass]'

프론트엔드 에셋 컴파일#

개발 중에는 프론트엔드 에셋을 수동으로 컴파일할 필요가 거의 없지만, 프로덕션 환경에서 에셋이 어떻게 컴파일되는지 테스트해야 할 경우 다음 명령으로 수행할 수 있습니다:

RAILS_ENV=production NODE_ENV=production bundle exec rake gitlab:assets:compile

이 명령은 모든 JavaScript 및 CSS 에셋을 컴파일하고 최소화하며, 다른 모든 프론트엔드 에셋(이미지, 폰트 등)과 함께 /public/assets에 복사합니다. 이 위치에서 쉽게 확인할 수 있습니다.

이모지 태스크#

이모지 별칭 파일(이모지 자동 완성에 사용)을 업데이트하려면 다음을 실행합니다:

bundle exec rake tanuki_emoji:aliases

폴백 이모지 이미지를 가져오려면 다음을 실행합니다:

bundle exec rake tanuki_emoji:import

현재 사용 가능한 이모지를 기반으로 이모지 다이제스트 파일(이모지 자동 완성에 사용)을 업데이트하려면 다음을 실행합니다:

bundle exec rake tanuki_emoji:digests

모든 이모지가 포함된 스프라이트 파일을 생성하려면 다음을 실행합니다:

bundle exec rake tanuki_emoji:sprite

자세한 지침은 이모지 업데이트 방법을 참고하세요.

프로젝트 템플릿 업데이트#

GitLab 팀원을 위한 프로젝트 템플릿 기여를 참고하세요.

라우트 목록 생성#

API 라우트의 전체 목록을 보려면 다음을 실행합니다:

bundle exec rake grape:path_helpers

생성된 목록에는 모든 API 엔드포인트와 기능적인 RESTful API 동사의 전체 목록이 포함됩니다.

Rails 컨트롤러의 경우 다음을 실행합니다:

bundle exec rails routes

생성하는 데 시간이 걸리므로, 빠른 참조를 위해 출력을 파일에 저장하는 것이 유용합니다.

오래된 ignored_columns 표시#

오래된 모든 ignored_columns 정의 목록을 보려면 다음을 실행합니다:

bundle exec rake db:obsolete_ignored_columns

해당 ignored_columns 정의에서 정의를 자유롭게 제거하세요.

GraphQL 쿼리 유효성 검사#

하나 이상의 프론트엔드 GraphQL 쿼리의 유효성을 확인하려면 다음을 실행합니다:

# 모든 쿼리 유효성 검사
bundle exec rake gitlab:graphql:validate
# 단일 쿼리 유효성 검사
bundle exec rake gitlab:graphql:validate[path/to/query.graphql]
# 디렉터리 유효성 검사
bundle exec rake gitlab:graphql:validate[path/to/queries]

이 명령은 각 쿼리에 대한 항목이 포함된 보고서를 출력하며, 유효성 검사에 실패한 경우 각 쿼리가 유효하지 않은 이유를 설명합니다.

유효성 검사 시 @client 필드를 제거하므로, 거짓 양성(false positive)을 피하기 위해 클라이언트 필드에 @client 지시어를 표시하는 것이 중요합니다.

GraphQL 쿼리 분석#

SQL의 ANALYZE와 유사하게, gitlab:graphql:analyze를 실행하여 쿼리 실행 비용을 추정할 수 있습니다.

사용법:

# 모든 쿼리 분석
bundle exec rake gitlab:graphql:analyze
# 단일 쿼리 분석
bundle exec rake gitlab:graphql:analyze[path/to/query.graphql]
# 디렉터리 분석
bundle exec rake gitlab:graphql:analyze[path/to/queries]

이 명령은 각 쿼리에 대한 보고서를 출력하며, 쿼리가 유효한 경우 복잡도도 포함됩니다.

복잡도는 경우에 따라 인수에 따라 달라지므로, 보고된 복잡도는 상한선에 대한 최선의 추정값입니다.

GraphQL 문서 및 스키마 정의 업데이트#

GitLab 스키마를 기반으로 GraphQL 문서를 생성하려면 다음을 실행합니다:

bundle exec rake gitlab:graphql:compile_docs

현재 상태에서 이 Rake 태스크는:

  • GraphQL 객체에 대한 출력을 생성합니다.

  • 출력을 doc/api/graphql/reference/_index.md에 배치합니다.

이는 스키마 파서와 헬퍼 메서드 같은 graphql-docs gem의 일부 기능을 사용합니다. 문서 생성기 코드는 자체 구현이므로, Haml 템플릿 사용 및 Markdown 파일 생성과 같은 더 많은 유연성을 제공합니다.

콘텐츠를 편집하려면 다음을 편집해야 할 수 있습니다:

  • 템플릿: tooling/graphql/docs/templates/default.md.haml에서 템플릿을 편집할 수 있습니다. 실제 렌더러는 Tooling::Graphql::Docs::Renderer에 있습니다.

  • 코드의 해당 description 필드: 이 필드는 머신 가독형 스키마 파일 업데이트를 수행하며, 앞서 설명한 rake 태스크에서 사용됩니다.

@parsed_schema는 graphql-docs gem이 사용 가능하도록 기대하는 인스턴스 변수입니다. Gitlab::Graphql::Docs::Helper는 우리가 사용하는 object 메서드를 정의합니다. 또한 표시하고 싶은 새로운 유형에 대한 새 메서드를 구현해야 할 위치이기도 합니다.

머신 가독형 스키마 파일 업데이트#

GitLab 스키마를 기반으로 GraphQL 스키마 파일을 생성하려면 다음을 실행합니다:

bundle exec rake gitlab:graphql:schema:dump

이는 GraphQL Ruby의 내장 Rake 태스크를 사용하여 IDL 및 JSON 형식 모두로 파일을 생성합니다.

문서 및 스키마 정의 업데이트#

다음 명령은 GraphQL 문서 및 스키마 정의 업데이트와 머신 가독형 스키마 파일 업데이트의 목적을 결합합니다:

bundle exec rake gitlab:graphql:update_all

감사 이벤트 유형 문서 업데이트#

감사 이벤트 유형 문서 업데이트에 대한 자세한 내용은 문서 생성을 참고하세요.

Error Tracking 기능을 위한 OpenAPI 클라이언트 업데이트#

이 Rake 태스크를 실행하려면 docker가 설치되어 있어야 합니다.

gems/error_tracking_open_api에 있는 OpenAPI 클라이언트의 생성된 코드를 업데이트하려면 다음 명령을 실행합니다:

# rake 태스크 실행
bundle exec rake gems:error_tracking_open_api:generate

# 변경 사항 검토 및 테스트

# 변경 사항 커밋
git commit -m 'Update ErrorTrackingOpenAPI from OpenAPI definition' gems/error_tracking_open_api

차단된 SSH 키 업데이트#

gitlab:security:update_banned_ssh_keys Rake 태스크를 사용하여 Git 리포지터리에서 차단된 SSH 키 목록을 업데이트할 수 있습니다:

  • SSH 공개 키가 포함된 공개 원격 Git 리포지터리를 찾습니다. 공개 키 파일의 확장자는 .pub이어야 합니다.

  • /tmp/ 디렉터리에 원격 Git 리포지터리를 저장할 충분한 공간이 있는지 확인합니다.

  • SSH 키를 차단 키 목록에 추가하려면 GIT_URL 및 OUTPUT_FILE을 적절한 값으로 바꿔 다음 명령을 실행합니다:

# @param git_url - Remote Git URL.
# @param output_file - Update keys to an output file. Default is config/security/banned_ssh_keys.yml.

bundle exec rake "gitlab:security:update_banned_ssh_keys[GIT_URL, OUTPUT_FILE]"

이 태스크는 원격 리포지터리를 클론하고, .pub으로 끝나는 파일을 찾아 파일 시스템을 재귀적으로 순회한 다음, 해당 파일들을 SSH 공개 키로 파싱하고 공개 키 지문을 output_file에 추가합니다. config/security/banned_ssh_keys.yml의 콘텐츠는 GitLab에서 읽어 메모리에 보관됩니다. 이 파일의 크기를 1메가바이트를 초과하도록 늘리는 것은 권장하지 않습니다.

현재 내비게이션 구조를 YAML로 출력#

이 태스크는 현재 환경 설정(라이선스, 기능 플래그, 프로젝트/그룹)에 의존하므로 실행 시마다 또는 환경마다 출력이 다를 수 있습니다. 향후 반복에서 출력을 표준화하는 방안을 검토할 예정입니다.

제품, UX, 기술 문서 담당자는 전체 GitLab 내비게이션을 감사할 방법이 필요하지만, lib/sidebars의 코드를 직접 검토하는 것이 어려울 수 있습니다. gitlab:nav:dump_structure Rake 태스크를 통해 전체 내비게이션 구조를 YAML로 덤프할 수 있습니다:

bundle exec rake gitlab:nav:dump_structure

개발자를 위한 Rake 태스크

GitLab v19.1
Tier: Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
원문 보기
요약

Rake 태스크는 개발자 및 GitLab에 기여하는 분들을 위해 제공됩니다. 데이터베이스 사용자에게 고급 권한이 없는 경우, 이 명령을 실행하기 전에 데이터베이스를 수동으로 생성해야 합니다. setup 태스크는 gitlab:setup의 별칭입니다.

Rake 태스크는 개발자 및 GitLab에 기여하는 분들을 위해 제공됩니다.

개발자 시드로 데이터베이스 설정#

데이터베이스 사용자에게 고급 권한이 없는 경우, 이 명령을 실행하기 전에 데이터베이스를 수동으로 생성해야 합니다.

bundle exec rake setup

setup 태스크는 gitlab:setup의 별칭입니다. 이 태스크는 db:reset을 호출하여 데이터베이스를 생성하고, db:seed_fu를 호출하여 데이터베이스에 시드 데이터를 삽입합니다. db:setup은 db:seed를 호출하지만 아무런 동작도 하지 않습니다.

환경 변수#

MASS_INSERT: 수백만 개의 사용자(200만), 프로젝트(500만) 및 관련 데이터를 생성합니다. 개발 중 느린 쿼리를 찾기 위해 이 옵션과 함께 시드를 실행하는 것이 강력히 권장됩니다. 프로세스를 완료하는 데 최대 20분이 추가로 소요될 수 있습니다.

Rails 모델 대량 삽입도 참고하세요.

LARGE_PROJECTS: 미리 정의된 URL 집합에서 (가져오기를 통해) 대형 프로젝트를 생성합니다.

시드 데이터#

모든 프로젝트 또는 특정 프로젝트에 이슈 시드 삽입#

gitlab:seed:issues 태스크를 사용하여 모든 프로젝트 또는 특정 프로젝트에 이슈 시드 데이터를 삽입할 수 있습니다:

# 모든 프로젝트
bin/rake gitlab:seed:issues

# 특정 프로젝트
bin/rake "gitlab:seed:issues[group-path/project-path]"

기본적으로 각 프로젝트에 대해 최근 5주 동안 주당 평균 2개의 이슈를 시드합니다.

Insights 차트를 위한 이슈 시드 삽입#

gitlab:seed:insights:issues 태스크를 사용하여 Insights 차트와 함께 사용하기 위한 이슈 시드 데이터를 삽입할 수 있습니다:

# 모든 프로젝트
bin/rake gitlab:seed:insights:issues

# 특정 프로젝트
bin/rake "gitlab:seed:insights:issues[group-path/project-path]"

기본적으로 각 프로젝트에 대해 최근 52주 동안 주당 평균 10개의 이슈를 시드합니다. 모든 이슈에는 팀, 유형, 심각도, 우선순위 라벨이 무작위로 지정됩니다.

하위 그룹이 포함된 그룹 시드 삽입#

gitlab:seed:group_seed 태스크를 사용하여 마일스톤/프로젝트가 포함된 하위 그룹이 있는 그룹에 시드 데이터를 삽입할 수 있습니다:

bin/rake "gitlab:seed:group_seed[subgroup_depth, username, organization_path]"

GitLab 인스턴스에 에픽 기능이 있는 경우 그룹에 에픽도 함께 시드됩니다.

러너 플릿 테스트 환경 시드 삽입#

gitlab:seed:runner_fleet 태스크를 사용하여 러너 및 파이프라인이 포함된 하위 그룹과 프로젝트가 있는 그룹으로 구성된 전체 러너 플릿을 시드합니다:

bin/rake "gitlab:seed:runner_fleet[username, registration_prefix, runner_count, job_count]"

기본적으로 Rake 태스크는 root 사용자 이름을 사용하여 40개의 러너와 400개의 job을 생성합니다.

%%{init: { "fontFamily": "GitLab Sans" }}%% graph TD accTitle: Seeding a runner fleet test environment accDescr: Diagram showing how the runner seed rake task seeds a full runner fleet with groups, subgroups, and projects with runners and pipelines

G1[Top-level group 1] --> G11
G2[Top-level group 2] --> G21
G11[Group 1.1] --> G111
G11[Group 1.1] --> G112
G111[Group 1.1.1] --> P1111
G112[Group 1.1.2] --> P1121
G21[Group 2.1] --> P211

P1111[Project 1.1.1.1<br><i>70% of jobs, sent to first 5 runners</i>]
P1121[Project 1.1.2.1<br><i>15% of jobs, sent to first 5 runners</i>]
P211[Project 2.1.1<br><i>15% of jobs, sent to first 5 runners</i>]

IR1[Instance runner]
P1111R1[Shared runner]
P1111R[Project 1.1.1.1 runners<br>20% total runners]
P1121R[Project 1.1.2.1 runners<br>49% total runners]
G111R[Group 1.1.1 runners<br>30% total runners<br><i>remaining jobs</i>]
G21R[Group 2.1 runners<br>1% total runners]

P1111 --> P1111R1
P1111 --> G111R
P1111 --> IR1
P1111 --> P1111R
P1121 --> P1111R1
P1121 --> IR1
P1121 --> P1121R
P211 --> P1111R1
P211 --> G21R
P211 --> IR1

classDef groups stroke-width:3px;
classDef projects stroke-width:2px;
class G1,G2,G11,G111,G112,G21 groups
class P1111,P1121,P211 projects

모니터링 대시보드의 커스텀 메트릭 시드 삽입#

모니터링 대시보드에서는 다양한 유형의 메트릭을 지원합니다.

이러한 메트릭을 가져오려면 다음을 실행합니다:

bundle exec rake 'gitlab:seed:development_metrics[your_project_id]'

취약점이 포함된 프로젝트 시드 삽입#

보안 취약점이 있는 프로젝트에 시드 데이터를 삽입할 수 있습니다.

# 모든 프로젝트에 시드 삽입
bin/rake 'gitlab:seed:vulnerabilities'

# 특정 프로젝트에 시드 삽입
bin/rake 'gitlab:seed:vulnerabilities[group-path/project-path]'

환경이 포함된 프로젝트 시드 삽입#

환경이 있는 프로젝트에 시드 데이터를 삽입할 수 있습니다.

기본적으로 각각 ENV_ 접두사를 가진 10개의 환경이 생성됩니다. 이 명령을 실행하려면 project_path만 필요합니다.

bundle exec rake "gitlab:seed:project_environments[project_path, seed_count, prefix]"

# 예시
bundle exec rake "gitlab:seed:project_environments[flightjs/Flight]"
bundle exec rake "gitlab:seed:project_environments[flightjs/Flight, 25, FLIGHT_ENV_]"

의존성이 포함된 그룹 시드 삽입#

bundle exec rake gitlab:seed:dependencies

CI 변수 시드 삽입#

CI 변수가 있는 프로젝트, 그룹, 또는 인스턴스에 시드 데이터를 삽입할 수 있습니다.

기본적으로 각 명령은 10개의 CI 변수를 생성합니다. 변수 이름에는 기본 접두사가 붙습니다(프로젝트 수준 변수는 VAR_, 그룹 수준 변수는 GROUP_VAR_, 인스턴스 수준 변수는 INSTANCE_VAR_).

인스턴스 수준 변수에는 환경 범위가 없습니다. 프로젝트 수준 및 그룹 수준 변수는 environment_scope가 지정되지 않은 경우 기본 "*" 환경 범위를 사용합니다. environment_scope가 "unique"로 설정되면 각 변수는 고유한 환경으로 생성됩니다.

# 프로젝트 수준 CI 변수로 프로젝트에 시드 삽입
# 이 명령을 실행하려면 `project_path`만 필요합니다.
bundle exec rake "gitlab:seed:ci_variables_project[project_path, seed_count, environment_scope, prefix]"

# 그룹 수준 CI 변수로 그룹에 시드 삽입
# 이 명령을 실행하려면 `group_name`만 필요합니다.
bundle exec rake "gitlab:seed:ci_variables_group[group_name, seed_count, environment_scope, prefix]"

# 인스턴스 수준 CI 변수로 인스턴스에 시드 삽입
bundle exec rake "gitlab:seed:ci_variables_instance[seed_count, prefix]"

# 예시
bundle exec rake "gitlab:seed:ci_variables_project[flightjs/Flight]"
bundle exec rake "gitlab:seed:ci_variables_project[flightjs/Flight, 25, staging]"
bundle exec rake "gitlab:seed:ci_variables_project[flightjs/Flight, 25, unique, CI_VAR_]"

bundle exec rake "gitlab:seed:ci_variables_group[group_name]"
bundle exec rake "gitlab:seed:ci_variables_group[group_name, 25, staging]"
bundle exec rake "gitlab:seed:ci_variables_group[group_name, 25, unique, CI_VAR_]"

bundle exec rake "gitlab:seed:ci_variables_instance"
bundle exec rake "gitlab:seed:ci_variables_instance[25, CI_VAR_]"

머지 트레인 개발을 위한 프로젝트 시드 삽입#

머지 트레인이 구성된 프로젝트와 20개의 머지 리퀘스트(각각 커밋 3개 포함)를 시드합니다. 명령:

rake gitlab:seed:merge_trains:project

자동화#

현재 데이터베이스를 완전히 초기화하고 시드 데이터를 다시 채우려는 경우, FORCE 환경 변수를 yes로 설정할 수 있습니다:

FORCE=yes bundle exec rake setup

이렇게 하면 동작 확인/안전 검사가 건너뛰어져 yes를 수동으로 입력하지 않아도 됩니다.

stdout 출력 무시#

스크립트가 많은 정보를 출력하므로 터미널이 느려질 수 있으며, 파일로 리디렉션하면 20G 이상의 로그가 생성될 수 있습니다. 출력이 필요 없는 경우, /dev/null로 리디렉션하면 됩니다:

echo 'yes' | bundle exec rake setup > /dev/null

stdout에서 질문을 볼 수 없으므로, 실행을 계속하려면 echo 'yes'를 사용하는 것이 좋습니다. 오류는 여전히 stderr에 출력되므로 오류를 놓칠 걱정은 없습니다.

추가 프로젝트 시드 옵션#

프로젝트 시드 방식을 변경하기 위해 전달할 수 있는 환경 플래그가 몇 가지 있습니다.

  • SIZE: 기본값은 8, 최대: 32. 생성할 프로젝트 수입니다.

  • LARGE_PROJECTS: 기본값은 false. 설정하면 테스트를 돕기 위해 6개의 대형 프로젝트를 클론합니다.

  • FORK: 기본값은 false. true로 설정하면 torvalds/linux를 5번 포크합니다. 대신 포크할 기존 프로젝트의 full_path로도 설정할 수 있습니다.

테스트 실행#

테스트를 실행하려면 다음 명령을 사용할 수 있습니다:

  • bin/rake spec: RSpec 스위트 실행

  • bin/rake spec:unit: 단위 테스트만 실행

  • bin/rake spec:integration: 통합 테스트만 실행

  • bin/rake spec:system: 시스템 테스트만 실행

bin/rake spec은 완료하는 데 상당한 시간이 걸립니다. 로컬에서 전체 테스트 스위트를 실행하는 대신, 변경 사항과 관련된 단일 테스트 또는 디렉터리를 실행하면 시간을 절약할 수 있습니다. 머지 리퀘스트를 제출하면 CI가 전체 테스트 스위트를 대신 실행해줍니다. 머지 리퀘스트에서 CI 상태가 녹색이면 전체 테스트 스위트가 통과된 것입니다.

rspec .은 실행할 수 없습니다. 이 명령은 /tmp에 있는 파일을 포함하여 찾을 수 있는 모든 _spec.rb 파일을 실행하려 합니다.

spec:unit, spec:integration, spec:system 태스크에 RSpec 커맨드라인 옵션을 전달할 수 있습니다. 예를 들어, bin/rake "spec:unit[--tag ~geo --dry-run]".

RSpec 테스트에서 단일 테스트 파일을 실행하려면 다음을 실행합니다:

bin/rspec spec/controllers/commit_controller_spec.rb

하나의 디렉터리 내 여러 테스트를 실행하려면:

  • bin/rspec spec/requests/api/: API만 테스트하려는 경우 RSpec 테스트 실행

머지 리퀘스트 파이프라인에서 실패한 RSpec 테스트를 로컬에서 실행#

머지 리퀘스트 파이프라인이 RSpec 테스트 실패로 실패한 경우, 다음 Rake 태스크를 사용하여 실패한 모든 테스트를 로컬에서 실행할 수 있습니다:

bin/rake spec:merge_request_rspec_failure

이 Rake 태스크에는 몇 가지 주의사항이 있습니다:

  • 로컬 머신에서 머지 리퀘스트의 소스 브랜치와 동일한 브랜치에 있어야 합니다.

  • 파이프라인이 완료되어 있어야 합니다.

  • 테스트 보고서가 파싱될 때까지 기다렸다가 다시 시도해야 할 수도 있습니다.

이 Rake 태스크는 처음 요청될 때만 파싱되는 단위 테스트 보고서 기능에 의존합니다.

테스트, Rake 태스크, 마이그레이션 속도 향상#

Spring은 Rails 애플리케이션 프리로더입니다. 애플리케이션을 백그라운드에서 계속 실행 상태로 유지하여 테스트, Rake 태스크, 마이그레이션을 실행할 때마다 부팅할 필요가 없도록 개발 속도를 높여줍니다.

사용하려면 ENABLE_SPRING 환경 변수를 1로 export해야 합니다:

export ENABLE_SPRING=1

또는 각 spec 실행 시 다음을 사용할 수 있습니다:

bundle exec spring rspec some_spec.rb

RuboCop 태스크#

초기 RuboCop TODO 목록 생성#

초기 목록을 생성하는 한 가지 방법은 rubocop:todo:generate Rake 태스크를 실행하는 것입니다:

bundle exec rake rubocop:todo:generate

특정 RuboCop 규칙에 대한 TODO 목록을 생성하려면, Rake 태스크에 쉼표로 구분된 인수로 전달합니다:

bundle exec rake 'rubocop:todo:generate[Gitlab/NamespacedClass,Lint/Syntax]'
bundle exec rake rubocop:todo:generate\[Gitlab/NamespacedClass,Lint/Syntax\]

일부 셸에서는 괄호를 이스케이프하거나 따옴표로 묶어야 합니다.

이후 진행 방법은 RuboCop 예외 해결을 참고하세요.

"그레이스풀 모드"로 RuboCop 실행#

RuboCop을 "그레이스풀 모드"로 실행할 수 있습니다. 이 모드에서는 "유예 기간"이 활성화된(Details: grace period 사용) 모든 활성화된 cop 규칙이 무음 처리됩니다.

실행 방법:

bundle exec rake 'rubocop:check:graceful'
bundle exec rake 'rubocop:check:graceful[Gitlab/NamespacedClass]'

프론트엔드 에셋 컴파일#

개발 중에는 프론트엔드 에셋을 수동으로 컴파일할 필요가 거의 없지만, 프로덕션 환경에서 에셋이 어떻게 컴파일되는지 테스트해야 할 경우 다음 명령으로 수행할 수 있습니다:

RAILS_ENV=production NODE_ENV=production bundle exec rake gitlab:assets:compile

이 명령은 모든 JavaScript 및 CSS 에셋을 컴파일하고 최소화하며, 다른 모든 프론트엔드 에셋(이미지, 폰트 등)과 함께 /public/assets에 복사합니다. 이 위치에서 쉽게 확인할 수 있습니다.

이모지 태스크#

이모지 별칭 파일(이모지 자동 완성에 사용)을 업데이트하려면 다음을 실행합니다:

bundle exec rake tanuki_emoji:aliases

폴백 이모지 이미지를 가져오려면 다음을 실행합니다:

bundle exec rake tanuki_emoji:import

현재 사용 가능한 이모지를 기반으로 이모지 다이제스트 파일(이모지 자동 완성에 사용)을 업데이트하려면 다음을 실행합니다:

bundle exec rake tanuki_emoji:digests

모든 이모지가 포함된 스프라이트 파일을 생성하려면 다음을 실행합니다:

bundle exec rake tanuki_emoji:sprite

자세한 지침은 이모지 업데이트 방법을 참고하세요.

프로젝트 템플릿 업데이트#

GitLab 팀원을 위한 프로젝트 템플릿 기여를 참고하세요.

라우트 목록 생성#

API 라우트의 전체 목록을 보려면 다음을 실행합니다:

bundle exec rake grape:path_helpers

생성된 목록에는 모든 API 엔드포인트와 기능적인 RESTful API 동사의 전체 목록이 포함됩니다.

Rails 컨트롤러의 경우 다음을 실행합니다:

bundle exec rails routes

생성하는 데 시간이 걸리므로, 빠른 참조를 위해 출력을 파일에 저장하는 것이 유용합니다.

오래된 ignored_columns 표시#

오래된 모든 ignored_columns 정의 목록을 보려면 다음을 실행합니다:

bundle exec rake db:obsolete_ignored_columns

해당 ignored_columns 정의에서 정의를 자유롭게 제거하세요.

GraphQL 쿼리 유효성 검사#

하나 이상의 프론트엔드 GraphQL 쿼리의 유효성을 확인하려면 다음을 실행합니다:

# 모든 쿼리 유효성 검사
bundle exec rake gitlab:graphql:validate
# 단일 쿼리 유효성 검사
bundle exec rake gitlab:graphql:validate[path/to/query.graphql]
# 디렉터리 유효성 검사
bundle exec rake gitlab:graphql:validate[path/to/queries]

이 명령은 각 쿼리에 대한 항목이 포함된 보고서를 출력하며, 유효성 검사에 실패한 경우 각 쿼리가 유효하지 않은 이유를 설명합니다.

유효성 검사 시 @client 필드를 제거하므로, 거짓 양성(false positive)을 피하기 위해 클라이언트 필드에 @client 지시어를 표시하는 것이 중요합니다.

GraphQL 쿼리 분석#

SQL의 ANALYZE와 유사하게, gitlab:graphql:analyze를 실행하여 쿼리 실행 비용을 추정할 수 있습니다.

사용법:

# 모든 쿼리 분석
bundle exec rake gitlab:graphql:analyze
# 단일 쿼리 분석
bundle exec rake gitlab:graphql:analyze[path/to/query.graphql]
# 디렉터리 분석
bundle exec rake gitlab:graphql:analyze[path/to/queries]

이 명령은 각 쿼리에 대한 보고서를 출력하며, 쿼리가 유효한 경우 복잡도도 포함됩니다.

복잡도는 경우에 따라 인수에 따라 달라지므로, 보고된 복잡도는 상한선에 대한 최선의 추정값입니다.

GraphQL 문서 및 스키마 정의 업데이트#

GitLab 스키마를 기반으로 GraphQL 문서를 생성하려면 다음을 실행합니다:

bundle exec rake gitlab:graphql:compile_docs

현재 상태에서 이 Rake 태스크는:

  • GraphQL 객체에 대한 출력을 생성합니다.

  • 출력을 doc/api/graphql/reference/_index.md에 배치합니다.

이는 스키마 파서와 헬퍼 메서드 같은 graphql-docs gem의 일부 기능을 사용합니다. 문서 생성기 코드는 자체 구현이므로, Haml 템플릿 사용 및 Markdown 파일 생성과 같은 더 많은 유연성을 제공합니다.

콘텐츠를 편집하려면 다음을 편집해야 할 수 있습니다:

  • 템플릿: tooling/graphql/docs/templates/default.md.haml에서 템플릿을 편집할 수 있습니다. 실제 렌더러는 Tooling::Graphql::Docs::Renderer에 있습니다.

  • 코드의 해당 description 필드: 이 필드는 머신 가독형 스키마 파일 업데이트를 수행하며, 앞서 설명한 rake 태스크에서 사용됩니다.

@parsed_schema는 graphql-docs gem이 사용 가능하도록 기대하는 인스턴스 변수입니다. Gitlab::Graphql::Docs::Helper는 우리가 사용하는 object 메서드를 정의합니다. 또한 표시하고 싶은 새로운 유형에 대한 새 메서드를 구현해야 할 위치이기도 합니다.

머신 가독형 스키마 파일 업데이트#

GitLab 스키마를 기반으로 GraphQL 스키마 파일을 생성하려면 다음을 실행합니다:

bundle exec rake gitlab:graphql:schema:dump

이는 GraphQL Ruby의 내장 Rake 태스크를 사용하여 IDL 및 JSON 형식 모두로 파일을 생성합니다.

문서 및 스키마 정의 업데이트#

다음 명령은 GraphQL 문서 및 스키마 정의 업데이트와 머신 가독형 스키마 파일 업데이트의 목적을 결합합니다:

bundle exec rake gitlab:graphql:update_all

감사 이벤트 유형 문서 업데이트#

감사 이벤트 유형 문서 업데이트에 대한 자세한 내용은 문서 생성을 참고하세요.

Error Tracking 기능을 위한 OpenAPI 클라이언트 업데이트#

이 Rake 태스크를 실행하려면 docker가 설치되어 있어야 합니다.

gems/error_tracking_open_api에 있는 OpenAPI 클라이언트의 생성된 코드를 업데이트하려면 다음 명령을 실행합니다:

# rake 태스크 실행
bundle exec rake gems:error_tracking_open_api:generate

# 변경 사항 검토 및 테스트

# 변경 사항 커밋
git commit -m 'Update ErrorTrackingOpenAPI from OpenAPI definition' gems/error_tracking_open_api

차단된 SSH 키 업데이트#

gitlab:security:update_banned_ssh_keys Rake 태스크를 사용하여 Git 리포지터리에서 차단된 SSH 키 목록을 업데이트할 수 있습니다:

  • SSH 공개 키가 포함된 공개 원격 Git 리포지터리를 찾습니다. 공개 키 파일의 확장자는 .pub이어야 합니다.

  • /tmp/ 디렉터리에 원격 Git 리포지터리를 저장할 충분한 공간이 있는지 확인합니다.

  • SSH 키를 차단 키 목록에 추가하려면 GIT_URL 및 OUTPUT_FILE을 적절한 값으로 바꿔 다음 명령을 실행합니다:

# @param git_url - Remote Git URL.
# @param output_file - Update keys to an output file. Default is config/security/banned_ssh_keys.yml.

bundle exec rake "gitlab:security:update_banned_ssh_keys[GIT_URL, OUTPUT_FILE]"

이 태스크는 원격 리포지터리를 클론하고, .pub으로 끝나는 파일을 찾아 파일 시스템을 재귀적으로 순회한 다음, 해당 파일들을 SSH 공개 키로 파싱하고 공개 키 지문을 output_file에 추가합니다. config/security/banned_ssh_keys.yml의 콘텐츠는 GitLab에서 읽어 메모리에 보관됩니다. 이 파일의 크기를 1메가바이트를 초과하도록 늘리는 것은 권장하지 않습니다.

현재 내비게이션 구조를 YAML로 출력#

이 태스크는 현재 환경 설정(라이선스, 기능 플래그, 프로젝트/그룹)에 의존하므로 실행 시마다 또는 환경마다 출력이 다를 수 있습니다. 향후 반복에서 출력을 표준화하는 방안을 검토할 예정입니다.

제품, UX, 기술 문서 담당자는 전체 GitLab 내비게이션을 감사할 방법이 필요하지만, lib/sidebars의 코드를 직접 검토하는 것이 어려울 수 있습니다. gitlab:nav:dump_structure Rake 태스크를 통해 전체 내비게이션 구조를 YAML로 덤프할 수 있습니다:

bundle exec rake gitlab:nav:dump_structure