正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

Omnibus GitLabリリースプロセス

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

公式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でビルドがトリガーされ、パッケージが作成されます。

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

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

すべてのビルドサーバーは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ビルドがトリガーされます。

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

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

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

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

開発マシン上での設定

  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.47.10.4+ce.0、7.10.4+ce.1、...
    v7.10.4-ee7.10.4+ee.0、7.10.4+ee.1、...
    v7.11.0.rc1-ee7.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でパッケージのビルドの進行状況を追跡することができます。成功したビルドの後、それらは自動的に弊社のpackages.gitlab.comリポジトリにプッシュされます。

クラウドイメージの更新

新しいイメージは以下のときにリリースされます:

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

新しいイメージは、パッケージリリースから3営業日以内にリリースされるべきです。

イメージ固有のリリースドキュメント: