• GitLab Pagesの要件
• GitLab.comのGitLabページ
• プロジェクト例
• カスタムエラーコード ページ
• GitLab ページのリダイレクト
• GitLabページのアクセスコントロール
• ページの公開解除
• 制限事項
• Pagesの特定の設定オプション
  • .gitlab-ci.yml プレーンHTMLウェブサイト用
  • .gitlab-ci.yml 静的サイトジェネレータ用
  • .gitlab-ci.yml 実際のコードもあるリポジトリに対して
  • 圧縮資産へのサービス
  • あいまいなURLの解決
• よくある質問
  • 作成したページをダウンロードできますか？
  • プロジェクトが非公開でも GitLab Pages を使えますか？
  • プロジェクトのウェブサイトを作成する前に、ユーザー/グループのウェブサイトを作成する必要がありますか？
• 既知のイシュー

GitLab Pagesを探索

このドキュメントは、GitLab Pagesが提供するオプションや設定を探るためのユーザーガイドです。

まずは GitLab Pages に慣れることから始めましょう：

• GitLab Pagesの紹介をお読みください。
• Pagesの使い方をご紹介します。
• GitLabインスタンス全体でGitLab Pagesを有効にする方法は、管理者向けドキュメントをご覧ください。

GitLab Pagesの要件

簡単に説明すると、GitLab Pagesにウェブサイトをアップロードするために必要なものです：

1. インスタンスのドメイン：GitLab Pagesに使用するドメイン名（管理者にお尋ねください）。
2. GitLab CI/CD:.gitlab-ci.yml ファイルで、リポジトリのルートディレクトリにpages という特定のジョブがあります。
3. 公開するコンテンツを含む、サイトのリポジトリ内のpublic というディレクトリ。
4. プロジェクトでGitLab Runnerを有効にします。

GitLab.comのGitLabページ

GitLab.comのGitLab Pagesを使ってウェブサイトをホストしている場合：

• GitLab.comのGitLab Pagesのドメイン名はgitlab.io。
• カスタムドメインとTLSのサポートが有効になっています。
• 共有ランナーはデフォルトで有効になっており、無料で提供され、あなたのウェブサイトを構築するために使用することができます。 必要であれば、あなた自身のランナーを持参することもできます。

プロジェクト例

GitLabPagesグループにあるサンプルプロジェクトの完全なリストをご覧ください。 貢献者は大歓迎です。

カスタムエラーコード ページ

アーティファクトに含まれるpublic/ ディレクトリのルートディレクトリに、それぞれ403.html と404.html ファイルを作成することで、独自の 403 エラーページと 404 エラーページを提供することができます。通常、これはプロジェクトのルートディレクトリですが、静的ジェネレータの設定によって異なる場合があります。

404.htmlの場合、さまざまなシナリオがあります：

• プロジェクトページ（/projectname/で提供）を使っていて、/projectname/non/existing_fileにアクセスしようとすると、GitLab Pages は最初に/projectname/404.htmlを提供しようとし、次に/404.htmlを提供しようとします。
• user/group Pages (served under/) を使っていて、/non/existing_file にアクセスしようとすると、GitLab Pages は/404.htmlを提供しようとします。
• カスタムドメインを使用して/non/existing_fileにアクセスしようとすると、GitLab Pages は/404.htmlだけを提供しようとします。

GitLab ページのリダイレクト

.htaccess や.conf ファイルのようなカスタムサーバ設定ファイルを使用することができないため、ページを別の場所にリダイレクトしたい場合は、HTTP meta refresh タグを使用します。

いくつかの静的サイトジェネレータは、手動でHTMLファイルを作成し、編集する必要がないように、その機能のためのプラグインを提供します。 たとえば、Jekyllはredirect-fromプラグインを持っています。

GitLabページのアクセスコントロール

ウェブサイトへのアクセスを制限するには、GitLab Pagesのアクセスコントロールを有効にします。

ページの公開解除

Pagesのコンテンツを削除したくなったら、右上の歯車アイコンからプロジェクトの設定を開き、Pagesに移動してください。ページを削除ボタンを押すと、Pagesのウェブサイトが削除されます。

制限事項

GitLabインスタンスの一般ドメイン (*.example.io) でPagesを使用する場合、サブサブドメインでHTTPSを使用することは_できません_。つまり、ユーザー名やグループ名にドットが含まれている場合、インスタンスンスfoo.bar、ドメインhttps://foo.bar.example.io 。 これはHTTP Over TLSプロトコルの制限です。 HTTPページをHTTPSにリダイレクトしなければ、HTTPページは引き続き動作します。

GitLab Pagesはサブグループのグループウェブサイトをサポートしていません。 作成できるのは最上位のグループウェブサイトのみです。

Pagesの特定の設定オプション

GitLab CI/CDを特定のユースケースに設定する方法を学びます。

.gitlab-ci.yml プレーンHTMLウェブサイト用

リポジトリに以下のファイルがあったとします：

├── index.html
├── css
│   └── main.css
└── js
    └── main.js

.gitlab-ci.yml public/ .public の回避策は、 が を自分自身にコピーして無限ループにならないようにするためです：cp public/

pages:
  script:
    - mkdir .public
    - cp -r * .public
    - mv .public public
  artifacts:
    paths:
      - public
  only:
    - master

.gitlab-ci.yml 静的サイトジェネレータ用

ステップバイステップのガイドについては、この文書を参照してください。

.gitlab-ci.yml 実際のコードもあるリポジトリに対して

GitLab のブランチはデフォルトではブランチやタグに依存せず、デプロイは.gitlab-ci.ymlで指定した内容だけに依存します。only パラメータでpages ジョブを制限することができます。新しいコミットがブランチにプッシュされるたびに、そのブランチをあなたのブランチ専用に使います。

そうすることで、プロジェクトのコードをmaster ブランチに置き、静的ジェネレータサイトをホストする orphan ブランチ（pagesと名付けましょう）を使うことができます。

このように、新しい空のブランチを作成することができます：

git checkout --orphan pages

この新しいブランチで最初に行われたコミットには親がなく、他のすべてのブランチやコミットから完全に切り離された新しい履歴のルートとなります。静的ジェネレータのソースファイルをpages ブランチにプッシュします。

以下は、.gitlab-ci.yml のコピーです。最も重要な行は最後の行で、pages ブランチのすべてを実行するように指定しています：

image: ruby:2.6

pages:
  script:
    - gem install jekyll
    - jekyll build -d public/
  artifacts:
    paths:
      - public
  only:
    - pages

master ブランチにさまざまなファイルがあり、Jekyll のソースファイルはpages ブランチ にあり、.gitlab-ci.ymlも含まれている例をご覧ください。

圧縮資産へのサービス

最近のブラウザの多くは、圧縮ファイル形式でのダウンロードをサポートしています。 これにより、ファイルサイズが小さくなり、ダウンロードが高速化されます。

非圧縮ファイルを提供する前に、Pagesは同じファイルが.gz 拡張子で存在するかどうかをチェックします。存在し、ブラウザが圧縮ファイルの受信をサポートしている場合、非圧縮ファイルの代わりにそのバージョンを提供します。

この機能を利用するには、Pagesにアップロードするアーティファクトがこのような構造になっている必要があります：

public/
├─┬ index.html
│ └ index.html.gz
│
├── css/
│   └─┬ main.css
│     └ main.css.gz
│
└── js/
    └─┬ main.js
      └ main.js.gz

これは.gitlab-ci.yml pages ジョブにscript: コマンドを入れることで実現できます：

pages:
  # Other directives
  script:
    # Build the public/ directory first
    - find public -type f -regex '.*\.\(htm\|html\|txt\|text\|js\|css\)$' -exec gzip -f -k {} \;

ファイルを事前に圧縮し、両方のバージョンをアーティファクトに含めることで、Pagesはファイルをオンデマンドで圧縮する必要なく、圧縮と非圧縮の両方のコンテンツのリクエストに対応できます。

あいまいなURLの解決

GitLab 11.8 で導入されました。

GitLab Pagesは、拡張子を含まないURLのリクエストを受け取ったとき、どのファイルを提供するかについて仮定します。

以下のファイルでデプロイされたPagesサイトを考えてみましょう：

public/
├─┬ index.html
│ ├ data.html
│ └ info.html
│
├── data/
│   └── index.html
├── info/
│   └── details.html
└── other/
    └── index.html

Pagesは、いくつかの異なるURLを通して、これらの各ファイルに到達することをサポートしています。 特に、URLでディレクトリのみが指定されている場合、常にindex.html 。 URLが存在しないファイルを参照していても、URLに.html を追加すると、存在するファイルにつながる場合、そのファイルが代わりに提供されます。 上記のPagesサイトで何が起こるかの例をいくつか示します：

よくある質問

作成したページをダウンロードできますか？

ジョブページからアーティファクトアーカイブをダウンロードするだけです。

プロジェクトが非公開でも GitLab Pages を使えますか？

GitLab Pages では、プロジェクトの公開レベルを非公開、内部、公開のどれに設定してもかまいません。

プロジェクトのウェブサイトを作成する前に、ユーザー/グループのウェブサイトを作成する必要がありますか？

最初にプロジェクトを作成し、http(s)://namespace.example.io/projectname。

既知のイシュー

既知のイシューのリストについては、GitLabの公開イシュー・トラッカーをご覧ください。