GitHub PagesサイトのJekyllビルドエラーについて

Jekyllのビルドエラーについて

ブランチから公開している場合、サイトの公開ソースに変更をプッシュした後で GitHub Pages がサイトのビルドを試行しない場合があります。

デプロイキーでプッシュしている。サイトのリポジトリへのプッシュを自動化する場合は、かわりにマシンユーザーを設定できます。詳しくは、「デプロイキーの管理」をご覧ください。
公開元をビルドするようにCIサービスを設定していない。たとえば、Travis CI は、ブランチをセーフリストに追加しない限り、gh-pages ブランチをビルドしません。詳細については、Travis CI の「ビルドのカスタマイズ」またはお使いの CI サービスのドキュメントを参照してください。

Note

サイトに対する変更は、その変更を GitHub Enterprise Server にプッシュしてから公開されるまでに、最大 10 分かかることがあります。

Jekyll がサイトのビルドを試行せず、エラーが発生した場合は、ビルドエラーメッセージが表示されます。 Jekyll ビルドエラーメッセージには主に 2 つのタイプがあります。

「Page build warning」メッセージは、ビルドは成功したものの、今後問題が生じないようにするために変更を行なう必要がある可能性が存在することを意味します。
「Page build failed」メッセージは、ビルドが完了できなかったことを意味します。 Jekyll が失敗の理由を検出できた場合、説明を含むエラーメッセージが表示されます。

ビルドエラーのトラブルシューティングの詳細については、「GitHub Pages サイトの Jekyll ビルドエラーに関するトラブルシューティング」を参照してください。

GitHub Enterprise Server上のリポジトリのビルド失敗の表示

GitHub Enterprise Server 上のサイトのビルドの失敗については、サイトのリポジトリの、 Settings タブに表示されます (ただし、ビルドの警告については表示されません) 。

ローカルでのJekyllビルドエラーメッセージの表示

サイトのテストをローカルで行なうことをお勧めします。それにより、ビルドエラーメッセージをコマンドラインで表示でき、変更を GitHub Enterprise Server にプッシュする前に、あらゆるビルドエラーに対処できます。詳しくは、「Jekyll を使用して GitHub Pages サイトをローカルでテストする」をご覧ください。

Pull Request中でのJekyllのビルドエラーメッセージの表示

ブランチから公開している場合、GitHub Enterprise Server の公開ソースを更新するために pull request を作成すると、その pull request の [チェック] タブにビルドエラーメッセージが表示されます。詳しくは、「ステータスチェックについて」をご覧ください。

カスタムの GitHub Actions ワークフローを使用して公開している場合、pull request でのビルドエラーメッセージを確認するには、pull_request トリガーに対してそのワークフローが実行されるように構成する必要があります。これを行う際は、ワークフローが pull_request イベントによってトリガーされた場合に、展開手順をスキップすることをお勧めします。これにより、pull request からの変更をサイトにデプロイすることなく、ビルドエラーを確認することができます。詳細については、「ワークフローをトリガーするイベント」および「ワークフローとアクションで式を評価する」を参照してください。

メールでのJekyllのビルドエラーメッセージの表示

ブランチから公開している場合は、GitHub Enterprise Server 上の公開元に変更をプッシュしたときに、GitHub Pages によって、サイトのビルドが試行されます。ビルドが失敗すると、プライマリメールアドレスにメールが送信されます。

Tip

お使いの GitHub Enterprise Server インスタンス上で送信メールのサポートが有効になっている場合にのみ、メールを受信します。詳しい情報については、サイト管理者にお問い合わせください。

カスタムの GitHub Actions ワークフローを使用して公開している場合、pull request でのビルドエラーに関する Email を受信するには、pull_request トリガーに対してそのワークフローが実行されるように構成する必要があります。これを行う際は、ワークフローが pull_request イベントによってトリガーされた場合に、展開手順をスキップすることをお勧めします。これにより、pull request からの変更をサイトにデプロイすることなく、ビルドエラーを確認することができます。詳細については、「ワークフローをトリガーするイベント」および「ワークフローとアクションで式を評価する」を参照してください。

サードパーティCIサービスでのPull Request中でのJekyllのビルドエラーメッセージの表示

各コミット後にエラーメッセージを表示するように、Travis CI などのサードパーティのサービスを構成できます。

公開ソースのルートに、以下の内容で Gemfile と呼ばれるファイルをまだ追加していない場合は、追加します。
```
source `https://rubygems.org`
gem `github-pages`
```
選択したテストサービス用にサイトのリポジトリを設定します。たとえば、Travis CI を使用するには、公開ソースのルートに .travis.yml という名前のファイルを追加し、次の内容を含めます。
```
language: ruby
rvm:
  - 2.3
script: "bundle exec jekyll build"
```
サードパーティのテストサービス内で、リポジトリを有効にする必要があるかもしれません。詳しい情報については、お使いのテストサービスのドキュメンテーションを参照してください。