Omnibus GitLabのリリースプロセス

私たちの主な目標は、どのバージョンのGitLabがLinuxパッケージに含まれているかを明確にすることです。

公式Linuxパッケージはどのようにビルドされますか

公式パッケージビルドは、GitLab Inc.によって完全に自動化されています。

2種類のビルドを区別できます:

• https://packages.gitlab.comへのリリース用パッケージ。
• S3バケットで利用可能なブランチからビルドされたテストパッケージ。

どちらのタイプも同じインフラストラクチャ上にビルドされます。

インフラストラクチャ

各パッケージは、対象とするプラットフォーム上にビルドされます（CentOS 6パッケージはCentOS6サーバー、Debian 8パッケージはDebian 8サーバーというように）。ビルドサーバーの数は異なりますが、プラットフォームごとに少なくとも1つのビルドサーバーが常に存在します。

omnibus-gitlabプロジェクトは、GitLab CI/CDをフル活用しています。これは、omnibus-gitlabリポジトリへの各プッシュがGitLab CI/CDでビルドをトリガーし、パッケージを作成することを意味します。

GitLab.comはLinuxパッケージを使用してデプロイしているため、GitLab.comに問題が発生した場合や、パッケージのセキュリティリリースが原因で、パッケージをビルドするための個別のリモートが必要です。

このリモートはhttps://dev.gitlab.orgにあります。omnibus-gitlabプロジェクト (https://dev.gitlab.org) と他のパブリックリモートとの唯一の違いは、プロジェクトがアクティブなGitLab CIを持ち、ビルドサーバー上で実行されるプロジェクトに特定のRunnerが割り当てられていることです。これはすべてのGitLabコンポーネントにも当てはまります。例えば、GitLabシェルはhttps://dev.gitlab.orgでもGitLab.comとまったく同じです。

すべてのビルドサーバーはGitLab Runnerを実行し、すべてのRunnerはデプロイキーを使用してhttps://dev.gitlab.orgのプロジェクトに接続します。ビルドサーバーは、https://packages.gitlab.comの公式パッケージリポジトリと、テストパッケージを格納する特別なAmazon S3バケットにもアクセスできます。

ビルドプロセス

GitLab Incは、すべてのリリースのリリースタスクを自動化するためにrelease-tools projectを使用しています。リリースマネージャーがリリースプロセスを開始すると、いくつかの重要なことが行われます:

1. プロジェクトのすべてのリモートが同期されます。
2. コンポーネントのバージョンはGitLab CE/EEリポジトリ（例: VERSION、GITLAB_SHELL_VERSION）から読み取り、omnibus-gitlabリポジトリに書き込まれます。
3. 特定のGitタグが作成され、omnibus-gitlabリポジトリに同期されます。

omnibus-gitlabリポジトリ（https://dev.gitlab.org）が更新されると、GitLab CIビルドがトリガーされます。

具体的な手順は、.gitlab-ci.yml omnibus-gitlabリポジトリのファイルに記載されています。ビルドは、すべてのプラットフォームで同時に実行されます。

ビルド中、omnibus-gitlabはソースロケーションから外部ライブラリをプルし、GitLab、GitLabシェル、GitLab WorkhorseなどのGitLabコンポーネントはhttps://dev.gitlab.orgからプルされます。

ビルドが完了し、.debまたは.rpmパッケージがビルドされると、ビルドタイプのパッケージに応じて、https://packages.gitlab.comまたは一時的なS3バケット（30日以上前のファイルはパージされます）にプッシュされます。

コンポーネントバージョンを手動で指定する

開発マシン上

1. パッケージ化するGitLabのタグを選択します（例: v6.6.0）。

2. omnibus-gitlabリポジトリにリリースブランチを作成します（例: 6-6-stable）。

3. リリースブランチが既に存在する場合（たとえば、パッチリリースを実行している場合）、ローカルマシンに最新の変更をプルするようにしてください:

   git pull https://gitlab.com/gitlab-org/omnibus-gitlab.git 6-6-stable # existing release branch

4. support/set-revisionsを使用して、config/software/のファイルのリビジョンを設定します。Git SHA1のタグ名を調べて、ダウンロードソースをhttps://dev.gitlab.orgに設定します。EEリリースにはset-revisions --eeを使用します:

   # usage: set-revisions [--ee] GITLAB_RAILS_REF GITLAB_SHELL_REF GITALY_REF GITLAB_ELASTICSEARCH_INDEXER_REF
   
   # For GitLab CE:
   support/set-revisions v1.2.3 v1.2.3 1.2.3 1.2.3 1.2.3
   
   # For GitLab EE:
   support/set-revisions --ee v1.2.3-ee v1.2.3 1.2.3 1.2.3 1.2.3

5. 新しいバージョンをリリースブランチにコミットします:

   git add VERSION GITLAB_SHELL_VERSION GITALY_SERVER_VERSION
   git commit

6. GitLabタグに対応するomnibus-gitlabに注釈付きタグを作成します。omnibus-gitlabタグは、MAJOR.MINOR.PATCH+OTHER.OMNIBUS_RELEASEのようになります。MAJOR.MINOR.PATCHはGitLabのバージョン、OTHERはce、ee、rc1（またはrc1.ee）のようになり、OMNIBUS_RELEASEは数値（0から始まる）です:

   git tag -a 6.6.0+ce.0 -m 'Pin GitLab to v6.6.0'

   omnibus-gitlabタグには、ハイフン-をどこにも使用しないでください。

   アップストリームタグをomnibus-gitlabタグシーケンスに変換する例:

   アップストリームタグ	omnibus-gitlabタグシーケンス
   v7.10.4	7.10.4+ce.0、7.10.4+ce.1、...
   v7.10.4-ee	7.10.4+ee.0、7.10.4+ee.1、...
   v7.11.0.rc1-ee	7.11.0+rc1.ee.0、7.11.0+rc1.ee.1、...

7. ブランチとタグをhttps://gitlab.comとhttps://dev.gitlab.orgの両方にプッシュします:

   git push git@gitlab.com:gitlab-org/omnibus-gitlab.git 6-6-stable 6.6.0+ce.0
   git push git@dev.gitlab.org:gitlab/omnibus-gitlab.git 6-6-stable 6.6.0+ce.0

   注釈付きタグをhttps://dev.gitlab.orgにプッシュすると、パッケージリリースがトリガーされます。

パッケージの公開

https://dev.gitlab.org/gitlab/omnibus-gitlab/buildsでパッケージのビルドの進捗状況を追跡できます。これらは、ビルドの成功後に自動的にPackagecloud repositoriesにプッシュされます。

クラウドイメージの更新

クラウドイメージのリリースプロセスについては、https://handbook.gitlab.com/handbook/alliances/cloud-images/に記載されています。

新しいイメージは、次の場合にリリースされます:

1. GitLabの新しい月次リリースがある場合。
2. セキュリティ脆弱性がパッチリリースで修正された場合。
3. イメージに影響を与える重大なイシューを修正するパッチがある。

新しいイメージは、パッケージリリースから3営業日以内にリリースする必要があります。

イメージ固有のリリースに関するドキュメント:

• （非推奨）OpenShift。