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

GitLab Pages並列デプロイ

  • プラン: Premium、Ultimate
  • 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated

並行デプロイを使用すると、GitLab Pagesサイトの複数のバージョンを同時に公開できます。各バージョンには、指定したパスプレフィックスに基づいた固有のURLがあります。

並列デプロイを次のように使用します:

  • 本番環境にマージする前に、開発ブランチで変更をテストするためのワークフローを強化します。
  • 作業中のプレビューを関係者と共有し、フィードバックを得ます。
  • 複数のソフトウェアバージョンのドキュメントを同時に維持します。
  • さまざまなオーディエンス向けにローカライズされたコンテンツを公開します。
  • 最終公開の前にレビュー用のステージング環境を作成します。

サイトの各バージョンには、指定したパスプレフィックスに基づいた独自のURLが割り当てられます。これらの並列デプロイの存続期間を制御します。これらはデフォルトで24時間後に有効期限が切れますが、レビュータイムラインに合わせてこの期間をカスタマイズできます。

並行デプロイを作成する

前提条件:

並列デプロイを作成するには:

  1. お使いの.gitlab-ci.ymlファイルに、path_prefixを持つPagesジョブを追加します:

    pages:
  stage: deploy
  script:
    - echo "Pages accessible through ${CI_PAGES_URL}"
  pages:  # specifies that this is a Pages job and publishes the default public directory
    path_prefix: "$CI_COMMIT_BRANCH"

    path_prefixの値:

    • 小文字に変換されます。
    • 数字(0-9)、文字(a-z)、ピリオド(.)を含めることができます。
    • その他の文字はハイフン(-)に置き換えられます。
    • ハイフン(-)またはピリオド(.)で開始または終了することはできません。これらは削除されます。
    • 63バイト以下である必要があります。それよりも長い場合は切り捨てられます。

  2. オプション。動的なプレフィックスを使用したい場合は、path_prefixでCI/CD変数を使用します。例:

    pages:
  path_prefix: "mr-$CI_MERGE_REQUEST_IID" # Results in paths like mr-123

  3. オプション。そのデプロイの有効期限を設定するには、expire_inを追加します:

    pages:
  pages:
    path_prefix: "$CI_COMMIT_BRANCH"
    expire_in: 1 week

    デフォルトでは、並行デプロイは24時間後に期限切れになります。

  4. 変更をコミットし、リポジトリにプッシュする。

デプロイは次の場所からアクセスできます:

  • ユニークドメインを使用する場合: https://project-123456.gitlab.io/your-prefix-name。
  • ユニークドメインを使用しない場合: https://namespace.gitlab.io/project/your-prefix-name。

サイトドメインと公開ディレクトリ間のURLパスは、path_prefixによって決定されます。たとえば、mainデプロイに/index.htmlのコンテンツがある場合、プレフィックスstagingを持つ並行デプロイは、同じコンテンツに/staging/index.htmlでアクセスできます。

パスの競合を防ぐため、サイトの既存フォルダー名と一致するパスプレフィックスの使用は避けてください。詳細については、パスの衝突を参照してください。

設定例

https://gitlab.example.com/namespace/projectのようなプロジェクトを考えます。デフォルトでは、メインのPagesデプロイは次の方法でアクセスできます:

  • ユニークドメインを使用する場合: https://project-123456.gitlab.io/。
  • ユニークドメインを使用しない場合: https://namespace.gitlab.io/project。

pages.path_prefixがプロジェクトのブランチ名(path_prefix = $CI_COMMIT_BRANCHなど)に設定されており、username/testing_featureという名前のブランチがある場合、この並行Pagesデプロイは以下からアクセスできます:

  • ユニークドメインを使用する場合: https://project-123456.gitlab.io/username-testing-feature。
  • ユニークドメインを使用しない場合: https://namespace.gitlab.io/project/username-testing-feature。

制限

並列デプロイの数は、ルートレベルのネームスペースによって制限されます。次の特定の制限については:

ネームスペース内のアクティブなデプロイの数をすぐに減らすには、いくつかのデプロイを削除します。詳細については、デプロイの削除を参照してください。

古いデプロイを自動的に削除するための有効期限を設定するには、デプロイの有効期限を参照してください。

有効期限

デフォルトでは、並行デプロイは24時間後に期限切れになり、その後削除されます。自己ホスト型インスタンスを使用している場合は、そのインスタンスの管理者が別のデフォルト期間を設定できます。

有効期限をカスタマイズするには、pages.expire_inを設定します。

デプロイが自動的に期限切れになるのを防ぐには、pages.expire_inをneverに設定します。

パスの衝突

pages.path_prefixは、CI/CD変数から動的な値を取得でき、これによりサイトの既存のパスと衝突する可能性があるPagesデプロイを作成できます。たとえば、次のパスを持つ既存のGitLab Pagesサイトがある場合:

/index.html
/documents/index.html

もしpages.path_prefixがdocumentsである場合、そのバージョンは既存のパスをオーバーライドします。言い換えれば、https://namespace.gitlab.io/project/documents/index.htmlはサイトのdocumentsデプロイ上の/index.htmlを指し、サイトのmainデプロイのdocuments/index.htmlを指すわけではありません。

CI/CD変数を他の文字列と組み合わせることで、パスの衝突の可能性を減らすことができます。例:

create-pages:
  stage: deploy
  script:
    - echo "Pages accessible through ${CI_PAGES_URL}"
  variables:
    PAGES_PREFIX: "" # No prefix by default (main)
  pages:  # specifies that this is a Pages job and publishes the default public directory
    path_prefix: "$PAGES_PREFIX"
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH # Run on default branch (with default PAGES_PREFIX)
    - if: $CI_COMMIT_BRANCH == "staging" # Run on main (with default PAGES_PREFIX)
      variables:
        PAGES_PREFIX: '_stg' # Prefix with _stg for the staging branch
    - if: $CI_PIPELINE_SOURCE == "merge_request_event" # Conditionally change the prefix for Merge Requests
      when: manual # Run pages manually on Merge Requests
      variables:
        PAGES_PREFIX: 'mr-$CI_MERGE_REQUEST_IID' # Prefix with the mr-<iid>, like `mr-123`

動的なプレフィックスのために変数を文字列と組み合わせる他の例:

  • pages.path_prefix: 'mr-$CI_COMMIT_REF_SLUG': mr-がプレフィックスされたブランチまたはタグ名 (mr-branch-nameなど)。
  • pages.path_prefix: '_${CI_MERGE_REQUEST_IID}_': _がプレフィックスおよびサフィックスされたマージリクエスト番号 (_123_など)。

以前のYAMLの例では、ユーザー定義のジョブ名を使用しています。

並行デプロイを使用してPages環境を作成する

並行GitLab Pagesデプロイを使用して、新しい環境を作成できます。例:

create-pages:
  stage: deploy
  script:
    - echo "Pages accessible through ${CI_PAGES_URL}"
  variables:
    PAGES_PREFIX: "" # no prefix by default (run on the default branch)
  pages:  # specifies that this is a Pages job and publishes the default public directory
    path_prefix: "$PAGES_PREFIX"
  environment:
    name: "Pages ${PAGES_PREFIX}"
    url: $CI_PAGES_URL
  rules:
    - if: $CI_COMMIT_BRANCH == "staging" # ensure to run on the default branch (with default PAGES_PREFIX)
      variables:
        PAGES_PREFIX: '_stg' # prefix with _stg for the staging branch
    - if: $CI_PIPELINE_SOURCE == "merge_request_event" # conditionally change the prefix on Merge Requests
      when: manual # run pages manually on Merge Requests
      variables:
        PAGES_PREFIX: 'mr-$CI_MERGE_REQUEST_IID' # prefix with the mr-<iid>, like `mr-123`

この設定により、ユーザーはUIを介して各GitLab Pagesデプロイにアクセスできます。Pagesに環境を使用する場合、すべてのPages環境はプロジェクト環境リストに表示されます。

また、類似する環境をグループ化することもできます。

以前のYAMLの例では、ユーザー定義のジョブ名を使用しています。

自動クリーンアップ

path_prefixを持つマージリクエストによって作成された並行Pagesデプロイは、マージリクエストがクローズまたはマージされると自動的に削除されます。

リダイレクトとの使用

リダイレクトでは絶対パスを使用します。並行デプロイはサブパスで利用できるため、リダイレクトが並行デプロイで機能するには、_redirectsファイルに追加の変更が必要です。

既存のファイルは常にリダイレクトルールよりも優先されるため、Splatプレースホルダーを使用してプレフィックス付きパスへのリクエストを捕捉できます。

お使いのpath_prefixが/mr-${$CI_MERGE_REQUEST_IID}である場合、この_redirectファイルの例を調整して、プライマリおよび並行デプロイの両方のリクエストをリダイレクトします:

# Redirect the primary deployment
/will-redirect.html /redirected.html 302

# Redirect parallel deployments
/*/will-redirect.html /:splat/redirected.html 302