GitLab チームメンバーによる公式ビルドインフラの使い方ガイド

GitLabのチームメンバーであれば、ビルドインフラストラクチャにアクセスしたり、インフラストラクチャにアクセスできる同僚にアクセスしたりすることができます。そのアクセス権を使ってパッケージをビルドすることができます。

gitlab-org/gitlab プロジェクトマージリクエストのテスト

gitlab-org/gitlab プロジェクトにマージリクエストgitlab-org/gitlab がある場合、パッケージやDockerイメージを使ってそのMRをテストすることができます。

MRに対応するCIパイプラインで、qa ステージのe2e:package-and-test ジョブを実行してトリガします：

  • omnibus-gitlab QAミラーのダウンストリームパイプラインで、テスト用のUbuntu 22.04パッケージとオールインワンのDockerイメージを提供します。
  • これらのアーティファクトを使用したgitlab-qa 。

omnibus-gitlab プロジェクト MR をテストします。

omnibus-gitlab プロジェクトのMRがあれば、パッケージやDockerイメージを使ってそのMRをテストすることができます。

GitLab プロジェクトと同様に、omnibus-gitlab の MR に対して実行されるパイプラインにも、パッケージまたは Docker イメージを取得する手動ジョブがあります。Trigger:ce-package とTrigger:ee-package のジョブはCEとEEパッケージとDockerイメージをビルドし、QAランを実行します。

GitLab コンポーネントの特定のブランチやバージョンを使用します。

GitLab RailsやGitalyのような主要なGitLabコンポーネントのバージョンは、以下のように管理されています：

  • *_VERSION ファイルはomnibus-gitlab リポジトリにあります。
  • *_VERSION ビルド中に存在する環境変数。

詳細は以下の表を参照してください：

ファイル名環境変数説明
VERSIONGITLAB_VERSIONGitLab RailsアプリケーションのGitリファレンスを制御します。デフォルトでは、GitLab-FOSSリポジトリのmaster ブランチを指します。GitLab リポジトリを使いたい場合は、環境変数ee を true に設定します。
GITALY_SERVER_VERSIONGITALY_SERVER_VERSION GitalyリポジトリのGitリファレンス。
GITLAB_PAGES_VERSIONGITLAB_PAGES_VERSION GitLab PagesリポジトリのGitリファレンス。
GITLAB_SHELL_VERSIONGITLAB_SHELL_VERSION GitLab ShellリポジトリのGitリファレンス。
GITLAB_ELASTICSEARCH_INDEXER_VERSIONGITLAB_ELASTICSEARCH_INDEXER_VERSION GitLab Elasticsearch Indexerリポジトリの Git リファレンス。EEビルドでのみ使用します。
GITLAB_KAS_VERSIONGITLAB_KAS_VERSION GitLab Kubernetes AgentServerリポジトリのGitリファレンス。

GitLab MRからe2e:package-and-test ジョブを実行している場合、GITLAB_VERSION 環境変数にはパイプラインに対応するコミット SHA が設定されます。その他の環境変数は、指定されていない場合、対応するファイルから入力され、トリガーされたパイプラインに渡されます。

note
環境変数は*_VERSION ファイルよりも優先されます。

コンポーネントのバージョンを一時的に指定

以下のいずれかの方法で、コンポーネントのバージョンを一時的に指定します：

  • *_VERSION ファイルを編集し、コミットしてプッシュしてパイプラインを開始しますが、MR がマージ準備完了となる前にこの変更を元に戻します。MRでこの差分に関する未解決のディスカッションを開き、忘れずに差し戻すことをお勧めします。

  • .gitlab-ci.yml ファイルで環境変数を設定し、パイプラインを開始するためにコミットしてプッシュしますが、MR がマージの準備ができたとマークされる前にこの変更を差し戻します。MRでこの差分に関する未解決のディスカッションを開き、忘れずに差し戻すことをお勧めします。

  • 環境変数をGit のプッシュオプションとして渡します。

     git push <REMOTE> -o ci.variable="<ENV_VAR>=<VALUE>"
   
 # Passing multiple variables
 git push <REMOTE> -o ci.variable="<ENV_VAR_1>=<VALUE_1>" -o ci.variable="<ENV_VAR_2>=<VALUE_2>"

    Note:これは、プッシュする変更がある場合にのみ有効です。リモートがすでにあなたのローカルブランチで更新されている場合は、新しいパイプラインは作成されません。

  • UI から環境変数を指定しながら手動でパイプラインを実行します。

環境変数はQA ミラーでトリガーされたダウンストリームパイプラインに渡され、ビルド時に使用されます。

ファイルを変更する代わりに環境変数を使用すること*_VERSION で、変更を戻す余分なステップを避ける *_VERSIONことができます。*_VERSION ファイルは *_VERSION、omnibus-gitlab のパッケージビルドを繰り返す必要がある場合に最も効率的ですが、変更が起こるのは GitLab コンポーネントだけです。この場合、*_VERSION ファイルを変更した後にパイプラインを実行すると、手動で新しいパイプラインを実行する代わりに、アップストリームコンポーネントの機能ブランチからの変更を取り込んで新しいパッケージをビルドするために再試行することができます。

GitLab コンポーネントの特定のミラーまたはフォークを使用します。

Omnibus がビルドするほとんどのソフトウェアのリポジトリソースは、omnibus-gitlab リポジトリの.custom_sources.yml ファイルにあります。環境変数を使って主要な GitLab コンポーネントを上書きすることができます。詳細は以下の表を確認してください：

環境変数説明
ALTERNATIVE_PRIVATE_TOKEN非公開リポジトリからプルする際に使用するアクセストークン。
GITLAB_ALTERNATIVE_REPOGitLab RailsアプリケーションのGitリポジトリの場所。
GITLAB_SHELL_ALTERNATIVE_REPO GitLab ShellのGitリポジトリの場所。
GITLAB_PAGES_ALTERNATIVE_REPO GitLab PagesのGitリポジトリ。
GITALY_SERVER_ALTERNATIVE_REPO GitalyのGitリポジトリです。
GITLAB_ELASTICSEARCH_INDEXER_ALTERNATIVE_REPO GitLab Elasticsearch Indexerの Git リポジトリです。
GITLAB_KAS_ALTERNATIVE_REPO GitLab KubernetesエージェントサーバのGitリポジトリの場所。

他のオペレーションシステム用のパッケージのビルド

前提条件

リリースミラーを使用してください：

  • Ubuntu 22.04以外のオペレーションシステム用のパッケージをビルドする場合。
  • 変更したパッケージがすべてのオペレーティングシステムでビルドできるようにしてください。

他のオペレーティング・システム用のパッケージをビルドするには：

  1. 必要に応じて、前のセクションで指定したように*_VERSION ファイルや環境変数を変更してください。GitLab-FOSSではなくGitLabリポジトリからのコミットを使うために、CI設定の ee 環境変数をtrue 。

  2. ブランチをリリースミラーにプッシュし、パイプラインをチェックします。

  3. パイプラインは、サポートされているすべてのオペレーティングシステム用のパッケージとDockerイメージをビルドします。