개발자를 위한 Rake 작업

개발자 및 GitLab에 기여하는 다른 사용자들을 위해 Rake 작업을 사용할 수 있습니다.

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

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

bundle exec rake setup

setup 작업은 gitlab:setup의 별칭입니다. 이 작업은 데이터베이스를 만들기 위해 db:reset을 호출하고 데이터베이스를 시드하려면 db:seed_fu를 호출합니다. db:setup은 db:seed를 호출하지만 아무 작업도 수행하지 않습니다.

환경 변수

MASS_INSERT: 수백만 개의 사용자(2백만), 프로젝트(5백만) 및 이에 관련된 내용을 생성합니다. 개발 중에 느린 쿼리를 확인하려면 시드를 실행하는 것이 강력히 권장됩니다. 프로세스 완료에 추가로 20분이 소요될 수 있습니다.

레일즈 모델 대량 삽입도 참조하세요.

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

Insights 차트 작업을 위해 특별히 이슈를 시딩할 수 있습니다. gitlab:seed:insights:issues 작업을 사용하세요. 

# 모든 프로젝트
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]"

그룹은 GitLab 인스턴스에 에픽 기능이 있는 경우 에픽과 함께 추가로 시드됩니다.

러너 테스트 환경 시드

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[프로젝트_ID]'

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

보안 취약점이 있는 프로젝트에 시드를 심을 수 있습니다. 

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

# 특정 프로젝트에 시드 심기
bin/rake 'gitlab:seed:vulnerabilities[그룹-경로/프로젝트-경로]'

환경이 있는 프로젝트 시드

프로젝트에 환경을 시드로 심을 수 있습니다.

기본적으로, 이 명령은 ENV_ 접두어가 있는 10개의 환경을 생성합니다. 이 명령을 실행하려면 project_path 만 필요합니다. 

bundle exec rake "gitlab:seed:project_environments[프로젝트_경로, 시드_수, 접두어]"

# 예시
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[프로젝트_경로, 시드_수, 환경_범위, 접두어]"

# 그룹에 그룹 수준 CI 변수를 시드 심기
# 이 명령을 실행하려면 `group_name` 만 필요합니다.
bundle exec rake "gitlab:seed:ci_variables_group[그룹_이름, 시드_수, 환경_범위, 접두어]"

# 인스턴스에 인스턴스 수준 CI 변수를 시드 심기
bundle exec rake "gitlab:seed:ci_variables_instance[시드_수, 접두어]"

# 예시
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[그룹_이름]"
bundle exec rake "gitlab:seed:ci_variables_group[그룹_이름, 25, staging]"
bundle exec rake "gitlab:seed:ci_variables_group[그룹_이름, 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에서 질문을 볼 수 없기 때문에 단순히 계속 실행하는 것을 원할 수 있습니다. 여전히 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에서 전체 테스트 스위트가 실행됩니다. 병합 요청의 Green 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/

병합 요청 파이프라인에서 실패한 테스트 실행하기

병합 요청 파이프라인이 RSpec 테스트 실패로 실패한 경우, 다음 Rake 작업을 사용하여 모든 실패한 테스트를 로컬에서 실행할 수 있습니다. 

bin/rake spec:merge_request_rspec_failure

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

  • 로컬 머신의 브랜치가 병합 요청의 소스 브랜치와 동일해야 합니다.
  • 파이프라인이 완료되어야 합니다.
  • 테스트 보고서를 구문 분석하고 다시 시도해야 할 수 있습니다.

이 Rake 작업은 첫 번째 요청시에만 구문 분석되는 unit test reports 기능에 의존합니다.

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

Spring은 Rails 애플리케이션 사전로더입니다. 애플리케이션을 매번 부팅할 필요 없이 개발 속도를 높여줍니다.

사용하려면 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 목록을 생성하려면 쉼표로 구분하여 인자로 전달하면 됩니다. 또는 다음과 같이 인자로 전달하면 됩니다. 

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

일부 쉘은 괄호를 이스케이프하거나 따옴표로 감싸도록 요구할 수 있습니다.

이어서 어떻게 진행해야 하는지에 대한 자세한 내용은 RuboCop 예외 해결을 참조하세요.

우아한 모드에서 RuboCop 실행

“우아한 모드”에서 RuboCop을 실행할 수 있습니다. 이는 “우아한 기간”(via 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:digests

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

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

bundle exec rake tanuki_emoji:sprite

새로운 이모지가 추가된 경우 스프라이트 시트의 크기가 변경될 수 있습니다. 그러한 변경에 대응하기 위해 먼저 위의 Rake 작업으로 emoji.png 스프라이트 시트를 생성한 다음 새 스프라이트 시트의 차원을 확인하고 SPRITESHEET_WIDTH 및 SPRITESHEET_HEIGHT 상수를 업데이트하세요.

프로젝트 템플릿 업데이트

템플릿에서 프로젝트를 시작하려면 해당 프로젝트를 내보내야 합니다. 최신 main 브랜치에서 다음을 실행합니다: 

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

이제 병합 요청을 생성하고 main에 병합합니다.

모든 템플릿이 아닌 단일 템플릿만 업데이트하려면 대괄호 사이에 템플릿 이름을 지정하세요. 예를 들어 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 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

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

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

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

참고: 해당 Rake 작업을 실행하려면 docker가 설치되어 있어야 합니다.

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

# rake 작업 실행
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 메가바이트를 초과하여 늘리는 것은 권장되지 않습니다.