개발자를 위한 Rake 작업

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

개발자 미리 작성된 시드를 사용하여 데이터베이스 설정

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

bundle exec rake setup

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

환경 변수

MASS_INSERT: (2m) 사용자, (5m) 프로젝트 및 그 관계를 만듭니다. 개발 중에 느린 쿼리를 잡는 데 유용합니다. 작업하는 동안 20분 정도 걸릴 수 있습니다.

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

LARGE_PROJECTS: 미리 정의된 URL 세트에서 대규모 프로젝트(가져오기를 통해)를 만듭니다.

시드 데이터

모든 프로젝트 또는 단일 프로젝트에 대한 이슈 시딩

gitlab:seed:issues 작업을 사용하여 모든 프로젝트 또는 지정된 프로젝트에 대한 이슈를 시드할 수 있습니다. 

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

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

기본적으로, 이 작업은 프로젝트 당 지난 5주간의 주 평균 2개의 이슈를 시드합니다.

통찰차트용 이슈 시드

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:seed:runner_fleet 작업을 사용하세요. 

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

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

graph TD G1[최상위 그룹 1] --> G11 G2[최상위 그룹 2] --> G21 G11[그룹 1.1] --> G111 G11[그룹 1.1] --> G112 G111[그룹 1.1.1] --> P1111 G112[그룹 1.1.2] --> P1121 G21[그룹 2.1] --> P211 P1111[프로젝트 1.1.1.1<br><i>작업량의 70%, 처음 5개의 러너에 전송</i>] P1121[프로젝트 1.1.2.1<br><i>작업량의 15%, 처음 5개의 러너에 전송</i>] P211[프로젝트 2.1.1<br><i>작업량의 15%, 처음 5개의 러너에 전송</i>] IR1[인스턴스 러너] P1111R1[공유 러너] P1111R[프로젝트 1.1.1.1 러너<br>총 러너의 20%] P1121R[프로젝트 1.1.2.1 러너<br>총 러너의 49%] G111R[그룹 1.1.1 러너<br>총 러너의 30%<br><i>남은 작업</i>] G21R[그룹 2.1 러너<br>총 러너의 1%] P1111 --> P1111R1 P1111 --> G111R P1111 --> IR1 P1111 --> P1111R P1121 --> P1111R1 P1121 --> IR1 P1121 --> P1121R P211 --> P1111R1 P211 --> G21R P211 --> IR1 classDef groups fill:#09f6,color:#000000,stroke:#333,stroke-width:3px; classDef projects fill:#f96a,color:#000000,stroke:#333,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]'

환경이 있는 프로젝트 시딩

환경이 있는 프로젝트를 시드할 수 있습니다.

기본적으로, project_path를 입력하여 실행해야 합니다. 이 명령은 ENV_ 접두어가 있는 10개의 환경을 생성합니다. 

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에서 질문을 볼 수 없기 때문에 그냥 계속 실행하고 싶을 수 있습니다. 여전히 stderr에 오류가 출력되므로 오류를 놓칠 걱정은 없습니다.

추가 프로젝트 시드 옵션

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

  • SIZE: 기본값은 8, 최대값: 32. 생성할 프로젝트 수.
  • LARGE_PROJECTS: 기본값은 false. 설정하면 테스트에 도움이 되도록 6개의 큰 프로젝트를 복제합니다.
  • FORK: 기본값은 false. true로 설정하면 torvalds/linux를 다섯 번 포크합니다. 기존 프로젝트 full_path로도 설정할 수 있습니다.

테스트 실행

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

  • bin/rake spec: RSpec 스위트 실행
  • bin/rake spec:unit: 단위 테스트만 실행
  • bin/rake spec:integration: 통합 테스트만 실행
  • bin/rake spec:system: 시스템 테스트만 실행

bin/rake spec는 통과하는 데 상당한 시간이 걸립니다. 지역에서 전체 테스트 스위트를 실행하는 대신 변경 사항과 관련된 단일 테스트 또는 디렉토리를 실행하여 많은 시간을 절약할 수 있습니다. 병합 요청을 제출한 후 CI가 전체 테스트 스위트를 실행합니다. 병합 요청의 녹색 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

한 디렉토리 안에 여러 테스트를 실행하려면:

  • RSpec 테스트를 테스트하려면 bin/rake spec/requests/api/ 실행

병합 요청 파이프라인에서 실패한 RSpec 테스트를 로컬에서 실행

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

bin/rake spec:merge_request_rspec_failure

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

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

이 Rake 작업은 처음으로 요청될 때에만 구문 분석되는 단위 테스트 보고서 기능에 의존합니다.

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

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

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

export ENABLE_SPRING=1

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

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 상수를 업데이트하십시오.

프로젝트 템플릿 업데이트

GitLab 팀 구성원을 위한 프로젝트 템플릿 기여를 참조하세요(project_templates.md#for-gitlab-team-members).

경로 목록 생성

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 패키지의 일부 기능을 사용하기 때문에 스키마 파싱기 및 도우미 메서드가 사용됩니다.

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

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

@parsed_schema는 graphql-docs 패키지에서 사용되는 인스턴스 변수이며, Gitlab::Graphql::Docs::Helper는 우리가 사용하는 object 메서드를 정의합니다. 여기에 새로운 타입의 새로운 메서드를 구현해야 하는 곳입니다.

기계 판독 가능한 스키마 파일 업데이트

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

bundle exec rake gitlab:graphql:schema:dump

이 작업은 IDL 및 JSON 형식의 파일을 생성하기 위해 GraphQL Ruby의 내장된 Rake 작업을 사용합니다.

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

다음 명령은 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. .pub 파일 확장자를 가진 SSH 공개 키 파일이 포함된 공개 원격 Git 저장소를 찾습니다.
  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메가바이트 이상으로 늘리는 것은 권장되지 않습니다.

현재 탐색 구조를 YAML로 출력

이 작업은 현재 환경 설정(라이선스, 기능 플래그, 프로젝트/그룹)에 의존하므로 실행마다 또는 환경에 따라 출력이 달라질 수 있습니다. 나중에 출력을 표준화하는 것을 고려할 수 있습니다.

제품, UX 및 기술 문서 작성팀은 GitLab 전체 탐색을 감사할 수 있는 방법이 필요하지만, lib/sidebars의 코드를 직접 검토하는 것에 익숙하지 않을 수도 있습니다. gitlab:nav:dump_structure Rake 작업을 통해 전체 탐색 구조를 YAML로 덤프할 수 있습니다. 

bundle exec rake gitlab:nav:dump_structure