개발자를 위한 Rake 작업

개발자 및 기타 GitLab에 기여하는 사람들을 위해 Rake 작업이 제공됩니다.

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

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

bundle exec rake setup

setup 작업은 gitlab:setup에 대한 별칭입니다. 이 작업은 데이터베이스를 생성하는 db:reset을 호출하고 데이터베이스를 씨드하는 db:seed_fu를 호출합니다. db:setup은 db:seed를 호출하지만 아무것도 수행하지 않습니다.

환경 변수

MASS_INSERT: 수백만 개의 사용자(2m), 프로젝트(5m) 및 관련 항목을 생성합니다. 개발 중에 느린 쿼리를 잡기 위해 씨드를 실행하는 것이 매우 권장됩니다. 프로세스에 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 차트용 이슈 생성

Tier: Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

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 작업을 사용하여 서브그룹을 포함하는 그룹을 씨드할 수 있습니다. 이 그룹은 GitLab 인스턴스에 에픽 기능이 있는 경우 에픽으로 추가됩니다. 

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

러너 플릿 테스트 환경 씨드

gitlab:seed:runner_fleet 작업을 사용하여 프로젝트와 러너, 파이프라인을 포함하는 그룹을 포함하는 러너 플릿을 씨드할 수 있습니다. 

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

기본값으로, 이 Rake 작업은 root 사용자를 사용하여 40개의 러너와 400개의 작업을 생성합니다.

모니터링 대시보드용 사용자 정의 메트릭 씨드

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

이러한 메트릭을 가져오려면 다음을 실행할 수 있습니다: 

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

취약점이 있는 프로젝트 씨드

프로젝트에 보안 취약점을 씨드할 수 있습니다. 

# 모든 프로젝트 씨드
bin/rake 'gitlab:seed:vulnerabilities'

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

환경이 있는 프로젝트 씨드

프로젝트에 환경을 씨드할 수 있습니다.

기본값으로, 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_]"

Merge Train 개발용 프로젝트 시드

Merge Train이 구성된 프로젝트에 20개의 Merge Request(각각 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를 다섯 번 포크합니다. 기존 프로젝트 full_path로도 설정할 수 있습니다.

테스트 실행

다음 명령어를 사용하여 테스트를 실행할 수 있습니다:

  • RSpec 스위트를 실행하려면 bin/rake spec을 사용합니다.
  • 단위 테스트만 실행하려면 bin/rake spec:unit을 사용합니다.
  • 통합 테스트만 실행하려면 bin/rake spec:integration을 사용합니다.
  • 시스템 테스트만 실행하려면 bin/rake spec:system을 사용합니다.

bin/rake spec을 실행하는 데 상당한 시간이 소요됩니다. 로컬에서 전체 테스트 스위트를 실행하는 대신 변경 내용과 관련된 단일 테스트나 디렉터리를 실행함으로써 많은 시간을 절약할 수 있습니다. Merge Request을 제출한 후에는 CI가 전체 테스트 스위트를 실행합니다. Merge Request에서 녹색 CI 상태는 전체 테스트 스위트가 통과되었음을 의미합니다.

rspec .를 실행할 수 없습니다. 이 명령은 찾을 수 있는 모든 _spec.rb 파일을 실행하려고 하므로 /tmp에 있는 파일도 실행됩니다.

spec:unit, spec:integration, spec:system 작업에 RSpec 명령줄 옵션을 전달할 수 있습니다. 예를 들어, bin/rake "spec:unit[--tag ~geo --dry-run]".

RSpec 테스트를 실행하려면 단일 테스트 파일을 실행할 수 있습니다: 

bin/rspec spec/controllers/commit_controller_spec.rb

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

  • API만 테스트하려면 bin/rspec spec/requests/api/를 사용합니다.

Merge Request 파이프라인에서 실패한 RSpec 테스트를 로컬에서 실행

Merge Request 파이프라인이 RSpec 테스트 실패로 실패한 경우, 다음 Rake 작업을 사용하여 머신에서 실패한 모든 테스트를 실행할 수 있습니다: 

bin/rake spec:merge_request_rspec_failure

이 Rake 작업에는 몇 가지 주의할 사항이 있습니다:

  • 머신에서 Merge Request의 원본 브랜치와 동일한 브랜치에 있어야 합니다.
  • 파이프라인이 완료되어야 합니다.
  • 테스트 보고서가 구문 분석되기를 기다려야 할 수 있습니다. 그런 다음 다시 시도해야 합니다.

이 Rake 작업은 첫 요청 시에만 파싱되는 단위 테스트 보고서 기능에 의존합니다.

테스트, Rake 작업 및 마이그레이션 가속화

Spring은 Rails 애플리케이션 사전 로더입니다. 애플리케이션을 계속 실행하여 각 테스트, Rake 작업 또는 마이그레이션을 실행할 때마다 애플리케이션을 매번 부팅할 필요가 없도록 하여 개발 속도를 높일 수 있습니다.

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

export ENABLE_SPRING=1

또는 각 스펙 실행 시 다음을 사용할 수 있습니다, 

bundle exec spring rspec some_spec.rb

RuboCop 작업

초기 RuboCop TODO 디렉터리 생성

초기 디렉터리을 생성하는 한 가지 방법은 Rake 작업 rubocop:todo:generate를 실행하는 것입니다: 

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을 “우아한 모드”로 실행할 수도 있습니다. 이는 “유예 기간”이 활성화된 모든 활성화된 cop 규칙을 음소거하는 것을 의미합니다 (Details: grace period를 통해 활성화됨).

실행: 

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:digests

이렇게 하면 현재 사용 가능한 이모지를 기반으로 fixtures/emojis/digests.json 파일이 업데이트됩니다.

모든 이모지를 포함하는 스프라이트 파일을 생성하려면 다음을 실행하세요: 

bundle exec rake tanuki_emoji:sprite

새로운 이모지가 추가되면 스프라이트 시트의 크기가 변경될 수 있습니다. 그런 경우에는 먼저 위의 Rake 작업으로 emoji.png 스프라이트 시트를 생성한 다음, 새 스프라이트 시트의 차원을 확인하고 SPRITESHEET_WIDTH 및 SPRITESHEET_HEIGHT 상수를 그에 맞게 업데이트해야 합니다.

프로젝트 템플릿 업데이트

템플릿에서 프로젝트를 시작하려면 이 프로젝트를 내보내는 것이 필요합니다. 최신 메인 브랜치에서 다음을 실행하세요: 

gdk start
bundle exec rake gitlab:update_project_templates
git checkout -b update-project-templates
git add vendor/project_templates
git commit
git push -u origin update-project-templates

이제 Merge Request을 생성하고 메인 브랜치에 Merge하세요.

모든 템플릿이 아닌 단일 템플릿을 업데이트하려면 대괄호 사이에 템플릿 이름을 지정하세요. 예를 들어 cluster_management 템플릿의 경우 다음을 실행하세요: 

bundle exec rake gitlab:update_project_templates\[cluster_management\]

라우트 디렉터리 생성

모든 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 필드를 제거하므로 거짓 긍정적인 결과를 피하기 위해 클라이언트 필드에 @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 젬의 일부 기능을 사용하고 있으며, 스키마 파서 및 보조 메서드를 활용합니다. 문서 생성기 코드는 graphql-docs 젬의 스키마 파서 및 보조 메서드를 활용하여 Iaml 템플릿을 사용하며 Markdown 파일을 생성합니다.

내용을 편집하려면 다음을 편집해야 할 수 있습니다:

  • 템플릿. tooling/graphql/docs/templates/default.md.haml에서 템플릿을 편집할 수 있습니다. 실제 렌더러는 Tooling::Graphql::Docs::Renderer에 있습니다.
  • 코드의 적용 가능한 description 필드. 이는 기계 판독 가능한 스키마 파일 업데이트에 사용되며, 앞서 설명한 rake 작업에서 사용됩니다.

@parsed_schema는 graphql-docs 젬에서 사용할 수 있는 인스턴스 변수입니다. 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

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

감사 이벤트 유형 문서를 업데이트하려면 문서 생성를 참조하세요.

오류 추적 기능용 OpenAPI 클라이언트 업데이트

note
이 Rake 작업을 실행하려면 도커가 설치되어 있어야 합니다.

gems/error_tracking_open_api 위치에 있는 OpenAPI 클라이언트용 생성된 코드를 업데이트하려면 다음 명령을 실행하세요. 

# 레이크 작업 실행
bundle exec rake gems:error_tracking_open_api:generate

# 변경 사항 검토 및 테스트

# 변경 사항 커밋
git commit -m 'OpenAPI 정의에서 ErrorTrackingOpenAPI 업데이트' gems/error_tracking_open_api

금지된 SSH 키 업데이트

gitlab:security:update_banned_ssh_keys Rake 작업을 사용하여 어떤 Git 리포지터리에서도 금지된 SSH 키를 추가할 수 있습니다.

  1. SSH 공개 키가 있는 공개 원격 Git 리포지터리를 찾습니다. 공개 키 파일은 .pub 파일 확장자를 가져야 합니다.
  2. /tmp/ 디렉터리에 원격 Git 리포지터리를 저장할 충분한 공간이 있는지 확인합니다.

  3. 금지된 키 디렉터리에 SSH 키를 추가하려면 다음 몤령을 사용하여 해당 명령을 실행하세요. GIT_URL과 OUTPUT_FILE을 적절한 값으로 대체하세요. 

    # @param git_url - 원격 Git URL.
# @param output_file - 출력 파일에 키를 업데이트합니다. 기본값은 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메가바이트 이상으로 늘리는 것은 권장되지 않습니다.