- GitLab Pagesの要件
- GitLab.comのGitLabページ
- プロジェクト例
- カスタムエラーコード ページ
- GitLab ページのリダイレクト
- GitLabページのアクセスコントロール
- ページの公開解除
- 制限事項
- Pagesの特定の設定オプション
- よくある質問
- 既知のイシュー
GitLab Pagesを探索
このドキュメントは、GitLab Pagesが提供するオプションや設定を探るためのユーザーガイドです。
まずは GitLab Pages に慣れることから始めましょう:
- GitLab Pagesの紹介をお読みください。
- Pagesの使い方をご紹介します。
- GitLabインスタンス全体でGitLab Pagesを有効にする方法は、管理者向けドキュメントをご覧ください。
GitLab Pagesの要件
簡単に説明すると、GitLab Pagesにウェブサイトをアップロードするために必要なものです:
- インスタンスのドメイン:GitLab Pagesに使用するドメイン名(管理者にお尋ねください)。
- GitLab CI/CD:
.gitlab-ci.yml
ファイルで、リポジトリのルートディレクトリにpages
という特定のジョブがあります。 - 公開するコンテンツを含む、サイトのリポジトリ内の
public
というディレクトリ。 - プロジェクトで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サイトで何が起こるかの例をいくつか示します:
URLパス | HTTP レスポンス | ファイル提供 |
---|---|---|
/
| 200 OK
| public/index.html
|
/index.html
| 200 OK
| public/index.html
|
/index
| 200 OK
| public/index.html
|
/data
| 200 OK
| public/data/index.html
|
/data/
| 200 OK
| public/data/index.html
|
/data.html
| 200 OK
| public/data.html
|
/info
| 200 OK
| public/info.html
|
/info/
| 200 OK
| public/info.html
|
/info.html
| 200 OK
| public/info.html
|
/info/details
| 200 OK
| public/info/details.html
|
/info/details.html
| 200 OK
| public/info/details.html
|
/other
| 302 Found
| public/other/index.html
|
/other/
| 200 OK
| public/other/index.html
|
/other/index
| 200 OK
| public/other/index.html
|
/other/index.html
| 200 OK
| public/other/index.html
|
public/data/index.html
が存在する場合、/data
と/data/
の両方の URL パスに対して、public/data.html
ファイルよりも優先されます。よくある質問
作成したページをダウンロードできますか?
ジョブページからアーティファクトアーカイブをダウンロードするだけです。
プロジェクトが非公開でも GitLab Pages を使えますか?
GitLab Pages では、プロジェクトの公開レベルを非公開、内部、公開のどれに設定してもかまいません。
プロジェクトのウェブサイトを作成する前に、ユーザー/グループのウェブサイトを作成する必要がありますか?
最初にプロジェクトを作成し、http(s)://namespace.example.io/projectname
。
既知のイシュー
既知のイシューのリストについては、GitLabの公開イシュー・トラッカーをご覧ください。