- 前提条件
- Dockerイメージの選択
- Jekyllのインストール
public
、出力するディレクトリを指定します。- アーティファクト用の
public
ディレクトリを指定します。 - Pagesサイトへの特定のブランチのデプロイ
- デプロイするステージの指定
- 重複コマンドの削除
- キャッシュされた依存関係でビルドを高速化
- 関連トピック
GitLab Pagesウェブサイトをゼロから作成します。
このチュートリアルでは、Pagesサイトをゼロから作成する方法を紹介します。 空のプロジェクトから始め、GitLab Runnerに指示を与える独自のCIファイルを作成します。 CI/CDパイプラインが実行されると、Pagesサイトが作成されます。
この例では、Jekyllの静的サイトジェネレータを使用しています(SSG)。 他のSSGは、同様の手順を実行します。 このチュートリアルを完了するには、JekyllやSSGに精通している必要はありません。
前提条件
この例に従うために、GitLabで空白のプロジェクトから始めましょう。 ルート(トップレベル)ディレクトリに3つのファイルを作成します。
-
.gitlab-ci.yml
実行したいコマンドを含むYAMLファイル。 今のところ、ファイルの内容は空白のままにしておいてください。 -
index.html
HTMLファイルは、例えば、あなたが好きなHTMLコンテンツを入力することができます:<html> <head> <title>Home</title> </head> <body> <h1>Hello World!</h1> </body> </html>
-
Gemfile
Rubyプログラムの依存関係を記述したファイルです。 この内容を入力してください:source "https://rubygems.org" gem "jekyll"
Dockerイメージの選択
この例では、RunnerはDockerイメージを使用してスクリプトを実行し、サイトをデプロイします。
この特定のRubyイメージはDockerHubで管理されています。
.gitlab-ci.yml
を編集し、最初の行に次のテキストを追加してください。
image: ruby:2.7
SSG のビルドにNodeJSが必要な場合は、ファイルシステムの一部として NodeJS を含むイメージを指定する必要があります。 たとえば、Hexoサイトの場合はimage: node:12.17.0
.
Jekyllのインストール
ローカルでJekyllを実行するには、ターミナルを開きます:
-
gem install bundler
を実行してBundlerをインストールします。 -
bundle install
を実行してGemfile.lock
を作成します。 -
bundle exec jekyll build
を実行してJekyllをインストールします。
.gitlab-ci.yml
、このように記述します:
script:
- gem install bundler
- bundle install
- bundle exec jekyll build
さらに、.gitlab-ci.yml
ファイルでは、各script
はjob
.A job
で整理されています。job
A job
には、特定のタスクに適用するスクリプトと設定が含まれています。
job:
script:
- gem install bundler
- bundle install
- bundle exec jekyll build
GitLab Pagesの場合、このjob
はpages
と呼ばれる特定の名前を持っています。この設定は、ジョブにGitLab PagesでウェブサイトをデプロイさせたいことをRunnerに伝えます:
pages:
script:
- gem install bundler
- bundle install
- bundle exec jekyll build
public
、出力するディレクトリを指定します。
GitLab Pages はpublic
というディレクトリにあるファイルのみを考慮します。
Jekyllは、構築されたウェブサイトの出力ディレクトリを指定するには、宛先(-d
)を使用しています:
pages:
script:
- gem install bundler
- bundle install
- bundle exec jekyll build -d public
アーティファクト用のpublic
ディレクトリを指定します。
さて、Jekyllはpublic
ディレクトリにファイルを出力しているため、Runnerはそれらを取得する場所を知る必要があります。アーティファクトはpublic
ディレクトリに格納されています:
pages:
script:
- gem install bundler
- bundle install
- bundle exec jekyll build -d public
artifacts:
paths:
- public
これを.gitlab-ci.yml
ファイルに貼り付けると、次のようになります:
image: ruby:2.7
pages:
script:
- gem install bundler
- bundle install
- bundle exec jekyll build -d public
artifacts:
paths:
- public
.gitlab-ci.yml
ファイルを保存し、コミットします。CI / CD > Pipelinesにアクセスすることで、パイプラインの実行を見ることができます。
成功したら、「設定」>「ページ」で、あなたのサイトが利用可能になったURLを表示します。
より高度なタスクを行いたい場合は、.gitlab-ci.yml
ファイルを利用可能な設定で更新することができます。GitLab CI/CD Lint Toolで CI 構文をチェックすることができます。
以下のトピックでは、CI/CDファイルに追加できるその他のオプションの例を示します。
Pagesサイトへの特定のブランチのデプロイ
特定のブランチからのみPagesサイトにデプロイしたい場合もあるでしょう。
まず、workflow
セクションを追加して、変更がブランチにプッシュされたときだけパイプラインが実行されるようにします:
image: ruby:2.7
workflow:
rules:
- if: '$CI_COMMIT_BRANCH'
pages:
script:
- gem install bundler
- bundle install
- bundle exec jekyll build -d public
artifacts:
paths:
- public
次に、マスターブランチに対してのみジョブを実行するようにパイプラインを設定します。
image: ruby:2.7
workflow:
rules:
- if: '$CI_COMMIT_BRANCH'
pages:
script:
- gem install bundler
- bundle install
- bundle exec jekyll build -d public
artifacts:
paths:
- public
rules:
- if: '$CI_COMMIT_BRANCH == "master"'
デプロイするステージの指定
GitLab CI/CDのデフォルトステージは、ビルド、テスト、デプロイの3つです。
本番環境にデプロイする前にスクリプトをテストし、ビルドしたサイトをチェックしたい場合は、master
にプッシュしたときに実行されるのとまったく同じようにテストを実行できます。
ジョブの実行ステージを指定するには、CIファイルにstage
:
image: ruby:2.7
workflow:
rules:
- if: '$CI_COMMIT_BRANCH'
pages:
stage: deploy
script:
- gem install bundler
- bundle install
- bundle exec jekyll build -d public
artifacts:
paths:
- public
rules:
- if: '$CI_COMMIT_BRANCH == "master"'
今度は CI ファイルに別のジョブを追加して、master
ブランチを除くすべてのブランチへのプッシュをテストするように指示します:
image: ruby:2.7
workflow:
rules:
- if: '$CI_COMMIT_BRANCH'
pages:
stage: deploy
script:
- gem install bundler
- bundle install
- bundle exec jekyll build -d public
artifacts:
paths:
- public
rules:
- if: '$CI_COMMIT_BRANCH == "master"'
test:
stage: test
script:
- gem install bundler
- bundle install
- bundle exec jekyll build -d test
artifacts:
paths:
- test
rules:
- if: '$CI_COMMIT_BRANCH != "master"'
test
ステージでジョブが実行さ test
れると、Jekyllはtest
というディレクトリにサイトを構築します。 ジョブはmaster
を除くすべてのブランチに影響します。
異なるジョブにステージを適用すると、同じステージのすべてのジョブは並行してビルドされます。 Web アプリケーションがデプロイされる前に複数のテストを必要とする場合、すべてのテストを同時に実行できます。
重複コマンドの削除
ジョブごとに同じスクリプトが重複しないように、before_script
セクションにスクリプトを追加することができます。
この例では、gem install bundler
とbundle install
が、pages
とtest
の両ジョブに対して実行されていました。
これらのコマンドをbefore_script
セクションに移動します:
image: ruby:2.7
workflow:
rules:
- if: '$CI_COMMIT_BRANCH'
before_script:
- gem install bundler
- bundle install
pages:
stage: deploy
script:
- bundle exec jekyll build -d public
artifacts:
paths:
- public
rules:
- if: '$CI_COMMIT_BRANCH == "master"'
test:
stage: test
script:
- bundle exec jekyll build -d test
artifacts:
paths:
- test
rules:
- if: '$CI_COMMIT_BRANCH != "master"'
キャッシュされた依存関係でビルドを高速化
ビルドを高速化するには、cache
パラメータを使用して、プロジェクトの依存関係のインストールファイルをキャッシュします。
この例では、bundle install
を実行すると、Jekyll の依存関係をvendor
ディレクトリにキャッシュします:
image: ruby:2.7
workflow:
rules:
- if: '$CI_COMMIT_BRANCH'
cache:
paths:
- vendor/
before_script:
- gem install bundler
- bundle install --path vendor
pages:
stage: deploy
script:
- bundle exec jekyll build -d public
artifacts:
paths:
- public
rules:
- if: '$CI_COMMIT_BRANCH == "master"'
test:
stage: test
script:
- bundle exec jekyll build -d test
artifacts:
paths:
- test
rules:
- if: '$CI_COMMIT_BRANCH != "master"'
この場合、Jekyllが構築するフォルダのリストから/vendor
ディレクトリを除外する必要があります。そうしないと、Jekyllはサイトと一緒にディレクトリの内容を構築しようとします。
ルート・ディレクトリに、_config.yml
というファイルを作成し、次の内容を追加します:
exclude:
- vendor
GitLab CI/CDはウェブサイトをビルドするだけでなく、継続的なテストをフィーチャーブランチにプッシュし、Bundlerでインストールした依存関係をキャッシュし、すべてのプッシュをmaster
ブランチに継続的にデプロイします。
関連トピック
詳しくは以下のブログ記事をご覧ください。
-
GitLab CI/CD
environments
を使って、ウェブアプリをステージングとプロダクションにデプロイしましょう。 - ジョブの順次実行、並列実行、カスタムパイプラインの構築方法をご紹介します。
- このウェブサイトhttps://docs.gitlab.comをデプロイするために、異なるプロジェクトから特定のディレクトリをプルする方法を学びます。
- GitLab Pagesを使ってコードカバレッジレポートを作成する方法を学びます。