• パッケージ
  • ビルドの繰り返し
  • ビルドバージョン
    • 通常の feature ブランチビルド
    • ナイトリービルド
    • タグ付きリリースビルド
• Dockerイメージ
  • QA ミラーでのトリガービルド
  • ナイトリービルド
• タグ付きリリースビルド

パッケージとDockerイメージのバージョン形式

パッケージ

omnibus-gitlab 継続的インテグレーションパイプラインによってビルドされたパッケージは、<build_version>-<build_iteration> という形式のバージョン文字列を持ちます。パイプラインは通常3種類のパッケージを生成します：

• 機能ブランチビルド
• 夜間ビルド
• タグ付きリリースビルド

ビルドの繰り返し

バージョン文字列は、バンドルされているコンポーネントの変更を含まない、関連するロジックの変更をパッケージ化するときにbuild_iteration を使用します。

エディションコンポーネントのceやeeは、apt やyum のようなパッケージマネージャに、EntepriseEdition のパッケージを Community Edition からのアップグレードとして扱うように指示します。

OMNIBUS_RELEASE コンポーネントは非推奨となり、常に0 に設定されます。歴史的に、OMNIBUS_RELEASE はomnibus-gitlab をターゲットとした素早いバグ修正を示しており、GitLab Rails や他のバンドルコンポーネントは変更されていませんでした。アップデートはユーザーに影響を与えるため、頻繁にセマンティックバージョンのアップデートが必要でした。このため、OMNIBUS_RELEASE は実際には役に立たず、もはや意味がありません。

ビルドバージョン

バージョン文字列のビルドバージョンのコンポーネントは、パッケージが機能ブランチなのか、ナイトリービルドなのか、タグ付きリリースなのかによって変わります。

通常の feature ブランチビルド

通常の機能ブランチのビルドでは、バージョン形式は<latest stable git tag>+rfbranch.<pipeline id>.<omnibus-gitlab SHA>-<build iteration> です。

上述したように、通常の機能ブランチビルドのbuild iteration は0 に設定されます。このタイプのバージョン文字列の例は13.1.1+rfbranch.159743.eb538eaf-0 です。

+rfbranch という文字列は、通常の機能ブランチからビルドされたパッケージを表します。また、apt やyum のようなパッケージマネージャが、安定版リリースパッケージからのアップグレードとみなすように、字句解析的に安定版ブランチの後に配置します。

ナイトリービルド

ナイトリーパッケージの場合、バージョン形式は<latest stable git tag>+rnightly.<pipeline id>.<omnibus-gitlab SHA>-<build iteration> です。

前述のように、夜間ビルドのbuild iteration は0 に設定されます。このタイプのバージョン文字列の例は13.1.1+rnightly.159756.b2b5f05e-0 です。

は+rnightly そのパッケージがナイトリービルドの出力 +rnightlyであることを示します。+rnightly パッケージマネージャがアルファベット順に比較した場合 +rnightly、最新の安定版 (stable) と+rfbranch パッケージの両方よりも大きいとみなされます。パッケージマネージャは、夜間ビルドパッケージを常にアップグレードパッケージ として扱います。

タグ付きリリースビルド

タグつきリリースビルドの場合、Git タグは<SemVer version>+<build iteration> という形式ですが、バージョン文字列は<SemVer version>-<build iteration> という形式に従います。

例えば、タグが13.1.0+rc42.ce.0,13.1.0+ce.0,13.1.0+ee.0 の場合、バージョン文字列はそれぞれ13.1.0-rc42.ee.0,13.1.0-ce.0,13.1.0-ee.0 となります。

上述したように、フィーチャーブランチやナイトリービルドとは異なり、これらのリリースのbuild iteration コンポーネントは以下の形式です。(ce|ee).0

Dockerイメージ

omnibus-gitlab CIパイプラインで作成されるDockerイメージは、前のステージでビルドされたUbuntuパッケージに基づいています。したがって、Dockerイメージのタグもパッケージのバージョン文字列と同じ情報を反映します。パッケージのバージョンで使用される+ シンボルはイメージタグでサポートされている文字ではないため、- に置き換えてスラッグを取得します。

原則として、Dockerイメージはパッケージバージョンのスラッグをタグとして使用します。また、すべてのDockerイメージは、ビルドされるホストに対応するDockerコンテナレジストリにプッシュされます。

イメージの参照はすべて

dev.gitlab.org:5005/gitlab/omnibus-gitlab/gitlab-(ce|ee):<slug of package version>

例えば、dev.gitlab.org:5005/gitlab/omnibus-gitlab/gitlab-ce:13.2.1-rfbranch.163015.32ed1c58-0 はバージョン13.2.1+rfbranch.163015.32ed1c58-0

この一般的なルールから外れる特別なケースを以下に示します。

QA ミラーでのトリガービルド

トリガーされたパイプラインの一部として作成されたDockerイメージ(PackageとQA run用)のタグは、トリガーの発生元によって決まります。トリガーがomnibus-gitlab パイプラインから発生した場合、イメージタグはパッケージバージョンのスラッグになります。しかし、トリガーが GitLab または GitLab-FOSS パイプラインから発生した場合、イメージタグはそのパイプラインに対応するコミットの SHA に設定されます。

これらのジョブはDockerhubリポジトリには公開されません。

ナイトリービルド

一般的な命名スキームに加えて、スケジュールされた夜間パイプラインでビルドされたDockerイメージにはnightly タグが付けられ、両方のタグはDockerhubリポジトリにもプッシュされます。

gitlab/gitlab-ee:nightly とgitlab/gitlab-ce:nightly は、利用可能な2つのエディションのイメージリファレンスを示します。

タグ付きリリースビルド

一般的な命名スキームに加えて、タグ付きリリースパイプラインによってビルドされたDockerイメージにもlatest 。