- 開発者シードによるデータベースのセットアップ
- テストの実行
- RuboCop タスク
- 初期 RuboCop TODO リストの作成
- フロントエンドアセットのコンパイル
- 絵文字タスク
- プロジェクトテンプレートの更新
- ルートリストの生成
- 廃止されたものを表示
ignored_columns - GraphQLクエリの検証
- GraphQLクエリの分析
- GraphQL ドキュメントとスキーマ定義の更新
- 監査イベントタイプのドキュメントの更新
- エラー追跡機能のための OpenAPI クライアントの更新
- 禁止されているSSHキーの更新
開発者のためのRakeタスク
Rakeタスクは開発者やGitLabに貢献する人のために用意されています。
開発者シードによるデータベースのセットアップ
データベースユーザーに上級権限がない場合は、このコマンドを実行する前に手動でデータベースを作成する必要があります。
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 タスクで、すべてのプロジェクトまたは指定したプロジェクトのイシューをシードできます：
# All projects
bin/rake gitlab:seed:issues
# A specific project
bin/rake "gitlab:seed:issues[group-path/project-path]"
デフォルトでは、プロジェクトごとに過去5週間、週平均2件のイシューがシードされます。
インサイトチャートへのイシューのシード
gitlab:seed:insights:issues タスクを使用して、インサイトチャート専用のイシューをシードできます：
# All projects
bin/rake gitlab:seed:insights:issues
# A specific project
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]'
脆弱性を持つプロジェクトをシードします。
プロジェクトにセキュリティ脆弱性をシードすることができます。
# Seed all projects
bin/rake 'gitlab:seed:vulnerabilities'
# Seed a specific project
bin/rake 'gitlab:seed:vulnerabilities[group-path/project-path]'
プロジェクトに環境をシードしてください。
プロジェクトに環境をシードできます。
デフォルトでは、10個の環境が作成され、それぞれの環境には接頭辞ENV_ がつきます。このコマンドを実行するために必要なのはproject_path だけです。
bundle exec rake "gitlab:seed:project_environments[project_path, seed_count, prefix]"
# Examples
bundle exec rake "gitlab:seed:project_environments[flightjs/Flight]"
bundle exec rake "gitlab:seed:project_environments[flightjs/Flight, 25, FLIGHT_ENV_]"
CI変数のシード
プロジェクト、グループ、インスタンスにCI変数をシードすることができます。
デフォルトでは、各コマンドは10個のCI変数を作成します。変数名の先頭には、デフォルトの接頭辞（プロジェクトレベルの変数はVAR_ 、グループレベルの変数はGROUP_VAR_ 、インスタンスレベルの変数はINSTANCE_VAR_ ）が付きます。
インスタンスレベルの変数は環境スコープを持ちません。プロジェクト・レベル変数とグループ・レベル変数は、 noenvironment_scope を environment_scope指定するとデフォルトの"*" 環境スコープを使用します。"unique" を指定environment_scope すると environment_scope、各変数はそれぞれ固有の環境で作成されます。
# Seed a project with project-level CI variables
# Only `project_path` is required to run this command.
bundle exec rake "gitlab:seed:ci_variables_project[project_path, seed_count, environment_scope, prefix]"
# Seed a group with group-level CI variables
# Only `group_name` is required to run this command.
bundle exec rake "gitlab:seed:ci_variables_group[group_name, seed_count, environment_scope, prefix]"
# Seed an instance with instance-level CI variables
bundle exec rake "gitlab:seed:ci_variables_instance[seed_count, prefix]"
# Examples
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 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 のテストでは、1 つのテストファイルを実行するために次のコマンドを実行します：
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 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 は「グレースフルモード」で実行できます。これは、「グレースピリオド」が有効になっている (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 アセットをコンパイルして minify し、他のすべてのフロントエンドのアセット (画像、フォントなど) とともに/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
マージリクエストを作成し、それを 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クエリの検証
1つまたは複数のフロントエンドのGraphQLクエリの有効性を確認するには、以下を実行します：
# Validate all queries
bundle exec rake gitlab:graphql:validate
# Validate one query
bundle exec rake gitlab:graphql:validate[path/to/query.graphql]
# Validate a directory
bundle exec rake gitlab:graphql:validate[path/to/queries]
これは各クエリのエントリーを含むレポートを出力し、各クエリが検証に合格しなかった場合に無効である理由を説明します。
@client バリデーション中にフィールドを取り除くので @client、誤検出を避けるために@client クライアントのフィールドをこの @clientディレクティブ@client でマークすることが重要 @clientです。
GraphQLクエリの分析
SQL のANALYZE と同様に、gitlab:graphql:analyze を実行してクエリの実行コストを見積もることができます。
使い方
# Analyze all queries
bundle exec rake gitlab:graphql:analyze
# Analyze one query
bundle exec rake gitlab:graphql:analyze[path/to/query.graphql]
# Analyze a directory
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のスキーマパーサーやヘルパーメソッドのような機能を使用しています。docsジェネレータのコードは私たちの側からのもので、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 の両方の形式でファイルを生成します。
ドキュメントとスキーマ定義の更新
次のコマンドは、Update GraphQL documentation and schema definitionsと Update machine-readable schemafilesの2つのコマンドを組み合わせたものです：
bundle exec rake gitlab:graphql:update_all
監査イベントタイプのドキュメントの更新
監査イベント・タイプのドキュメントの更新については、「ドキュメントの生成」を参照してください。
エラー追跡機能のための OpenAPI クライアントの更新
docker をインストールする必要があります。gems/error_tracking_open_api にある OpenAPI クライアントの生成コードを更新するには、以下のコマンドを実行してください：
# Run rake task
bundle exec rake gems:error_tracking_open_api:generate
# Review and test the changes
# Commit the changes
git commit -m 'Update ErrorTrackingOpenAPI from OpenAPI definition' 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 - 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メガバイト以上にすることは推奨されません。