- 개발자 시드로 데이터베이스 설정
- 테스트 실행
- RuboCop 작업
- 초기 RuboCop TODO 목록 생성
- 프론트엔드 자산 컴파일
- 이모지 작업
- 프로젝트 템플릿 업데이트
- 경로 목록 생성
- 사용되지 않는
ignored_columns표시 - GraphQL 쿼리 유효성 검사
- GraphQL 쿼리 분석
- GraphQL 문서 및 스키마 정의 업데이트
- 감사 이벤트 유형 문서 업데이트
- 오류 추적 기능을 위한 OpenAPI 클라이언트 업데이트
- 차단된 SSH 키 업데이트
- 현재 탐색 구조를 YAML로 출력
개발자를 위한 Rake 작업
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개의 이슈를 시드합니다.
인사이트 차트용 이슈 시드 설정
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[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
자동화
현재 데이터베이스를 지우고 종자(seed)를 다시 채우고 싶다면, 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를 설정하여 해당 프로젝트를 포크할 수도 있습니다.
테스트 실행
테스트를 실행하려면 다음 명령어를 사용할 수 있습니다:
-
bin/rake specRSpec 스위트를 실행합니다. -
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
하나의 디렉토리 내에서 여러 테스트를 실행하려면:
-
bin/rspec spec/requests/api/API만 테스트하려는 경우 RSpec 테스트를 실행합니다.
Merge Request 파이프라인에서 실패한 RSpec 테스트를 로컬에서 실행하기
Merge Request 파이프라인이 RSpec 테스트 실패로 실패한 경우, 다음 Rake 작업을 사용하여 로컬 머신에서 모든 실패한 테스트를 실행할 수 있습니다:
bin/rake spec:merge_request_rspec_failure
이 Rake 작업에 대한 몇 가지 주의 사항이 있습니다:
- 로컬 머신에서도 병합 요청의 소스 브랜치와 동일한 브랜치에 있어야 합니다.
- 파이프라인이 완료되어야 합니다.
- 테스트 보고서를 구문 분석하고 다시 시도해야 할 수 있습니다.
이 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 목록을 생성하려면 인수로 쉼표로 구분하여 전달합니다:
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).
실행:
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 팀원을 위한 프로젝트 템플릿 기여하기를 참조하세요.
경로 목록 생성
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 키 업데이트
다음 Git 리포지토리에서 gitlab:security:update_banned_ssh_keys Rake 작업을 사용하여
차단된 SSH 키를 추가할 수 있습니다:
-
SSH 공개 키를 포함하는 공개 원격 Git 리포지토리를 찾습니다.
공개 키 파일은.pub파일 확장자를 가져야 합니다. -
/tmp/ 디렉터리에 원격 Git 리포지토리를 저장하기에 충분한 공간이 있는지 확인합니다.
-
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로 출력
이 작업은 현재 환경 설정(라이센스, 기능 플래그, 프로젝트/그룹)에 따라 달라질 수 있으므로, 실행마다 출력이 달라질 수 있습니다. 향후 iteration에서 출력을 표준화할 수 있습니다.
제품, UX 및 기술 문서는 전체 GitLab 탐색을 감사할 수 있는 방법이 필요하지만
lib/sidebars의 코드를 직접 검토하는 데 편안하지 않을 수 있습니다.
전체 내비게이션 구조를 YAML로 덤프하려면 gitlab:nav:dump_structure Rake 작업을 사용하세요:
bundle exec rake gitlab:nav:dump_structure
도움말