Jekyllのビルドエラーについて
ブランチから公開している場合、サイトの公開ソースに変更をプッシュした後で GitHub Pages がサイトのビルドを試行しない場合があります。
- デプロイキーでプッシュしている。 サイトのリポジトリへのプッシュを自動化する場合は、かわりにマシンユーザーを設定できます。 詳しくは、「デプロイキーの管理」を参照してください。
- 公開元をビルドするようにCIサービスを設定していない。 たとえば、Travis CI は、ブランチをセーフ リストに追加しない限り、
gh-pages
ブランチをビルドしません。 詳細については、Travis CI の「ビルドのカスタマイズ」またはお使いの CI サービスのドキュメントを参照してください。
注: サイトに対する変更は、その変更を 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 によって、サイトのビルドが試行されます。 ビルドが失敗すると、プライマリメールアドレスにメールが送信されます。
お使いの 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"
-
サードパーティのテストサービス内で、リポジトリを有効にする必要があるかもしれません。 詳しい情報については、お使いのテストサービスのドキュメンテーションを参照してください。