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で整理されています。jobA 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 ブランチに継続的にデプロイします。

詳しくは以下のブログ記事をご覧ください。