GitHub Pages サイトの公開元を設定する

公開元について

変更が特定のブランチにプッシュされたときにサイトを公開できます。または、GitHub Actions ワークフローを記述してサイトを公開することもできます。

サイトのビルドプロセスを制御する必要がない場合は、変更が特定のブランチにプッシュされたときにサイトを公開することをお勧めします。公開ソースとして使用するブランチとフォルダーを指定できます。ソースブランチにはリポジトリ内の任意のブランチを指定でき、ソースフォルダーにはソースブランチのリポジトリ (/) のルートまたはソースブランチの /docs フォルダーのいずれかを指定できます。変更がソースブランチにプッシュされるたびに、ソースフォルダー内の変更が GitHub Pages サイトに公開されます。

Jekyll 以外のビルドプロセスを使用する場合、または専用ブランチでコンパイル済みの静的ファイルを保持したくない場合は、GitHub Actions ワークフローを記述してサイトを公開することをお勧めします。 GitHub Enterprise Cloud には、ワークフローの記述に役立つ一般的な公開シナリオ用のワークフローテンプレートが用意されています。

警告: エンタープライズが Enterprise Managed Users を使用しない限り、サイトのリポジトリがプライベートまたは内部であっても、GitHub Pages サイトは既定でインターネット上で一般公開されます。サイトのアクセス制御を管理することで、サイトをプライベートで公開できます。それ以外の場合、サイトのリポジトリにセンシティブなデータがあるなら、公開前にそのデータを取り除くのが良いでしょう。詳細については、「リポジトリについて」および「GitHub Pages サイトの可視性を変更する」を参照してください。

ブランチからの公開

公開元として使用するブランチがリポジトリ内に既に存在していることを確認します。
GitHub Enterprise Cloudで、サイトのリポジトリにアクセスしてください。
リポジトリ名の下にある [設定] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウンメニューを選び、 [設定] をクリックします。
サイドバーの [コードと自動化] セクションで、 [ ページ] をクリックします。
[ビルドとデプロイ] の [ソース] で、 [ソースからのデプロイ] を選択します。
[ビルドとデプロイ] で、ブランチドロップダウンメニューを使って、公開元を選びます。
必要に応じて、フォルダードロップダウンメニューを使って公開元のフォルダを選択します。
[保存] をクリックします。

ブランチからの公開のトラブルシューティング

Note

If your repository contains symbolic links, you will need to publish your site using a GitHub Actions workflow. For more information about GitHub Actions, see "GitHub Actions ドキュメント."

Note

ブランチから公開しようとしていて、サイトが自動的に公開されていない場合は、管理者アクセス許可と検証済みの電子メールアドレスを持つユーザーが公開ソースにプッシュしていることを確認してください。
GITHUB_TOKEN を使う GitHub Actions ワークフローによってプッシュされたコミットでは、GitHub Pages ビルドがトリガーされません。

公開ソースとして任意のブランチの docs フォルダーを選択し、後でリポジトリ内のそのブランチから /docs フォルダーを削除した場合、サイトはビルドされず、見つからない /docs フォルダーのページビルドエラーメッセージが表示されます。詳しくは、「GitHub Pages サイトの Jekyll ビルドエラーに関するトラブルシューティング」を参照してください。

GitHub Pagesサイトは、GitHub Pagesサイトを別のCIツールを使ってビルドするように設定している場合であっても、常にGitHub Actionsワークフローの実行によってデプロイされます。ほとんどの外部 CI ワークフローは、ビルド出力をリポジトリの gh-pages ブランチにコミットすることによって GitHub Pages に "デプロイ" し、通常は .nojekyll ファイルが含まれます。これが行われた場合、GitHub Actionsワークフローはブランチにビルドのステップが必要ない状態になっていることを検出し、サイトをGitHub Pagesサーバーにデプロイするのに必要なステップだけを実行します。

ビルドあるいはデプロイメントでの潜在的なエラーを見つけるには、リポジトリのワークフロー実行をレビューすることによって、GitHub Pagesサイトのためのワークフローの実行をチェックできます。詳しくは、「ワークフロー実行の履歴を表示する」を参照してください。エラーが発生した場合のワークフローの再実行について詳しくは、「ワークフローとジョブの再実行」をご覧ください。

カスタム GitHub Actions ワークフローによる公開

GitHub Actions を使用して公開するサイトを構成するには、次の手順を行います。

GitHub Enterprise Cloudで、サイトのリポジトリにアクセスしてください。
リポジトリ名の下にある [設定] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウンメニューを選び、 [設定] をクリックします。
サイドバーの [コードと自動化] セクションで、 [ ページ] をクリックします。
[ビルドとデプロイ] の [ソース] で、 [GitHub Actions] を選びます。
GitHub Enterprise Cloud により、いくつかのワークフローテンプレートが提案されます。サイトを公開するワークフローが既にある場合、この手順をスキップできます。それ以外の場合、GitHub Actions ワークフローを作成するオプションのいずれかを選択します。カスタムワークフローの作成に関する詳しい情報については、「サイトを公開するカスタム GitHub Actions ワークフローの作成」を参照してください。

GitHub Pages では、特定のワークフローを GitHub Pages 設定に関連付けません。ただし、GitHub Pages 設定は、最近サイトをデプロイしたワークフロー実行にリンクされます。

サイトを公開するカスタム GitHub Actions ワークフローの作成

GitHub Actions について詳しくは、「GitHub Actions ドキュメント」をご覧ください。

GitHub Actions で発行するようにサイトを構成する場合、GitHub Enterprise Cloud により、一般的な公開シナリオのワークフローテンプレートが提案されます。ワークフローの一般的なフローは、次のとおりです。

リポジトリの既定のブランチへのプッシュがあるたびに、またはワークフローが [Actions] タブから手動で実行されるたびに、トリガーされます。
actions/checkout アクションを使用してリポジトリの内容をチェックアウトします。
サイトで必要な場合、静的サイトファイルをビルドします。
actions/upload-pages-artifact アクションを使用して静的ファイルを成果物としてアップロードします。
ワークフローが既定のブランチへのプッシュによってトリガーされた場合、actions/deploy-pages アクションを使用して成果物をデプロイします。ワークフローが pull request によってトリガーされた場合、この手順はスキップされます。

ワークフローテンプレートでは、github-pages という名前のデプロイ環境を使用します。 github-pages という名前の環境がリポジトリにまだ含まれていない場合、この環境は自動的に作成されます。既定のブランチのみがこの環境にデプロイできるように、デプロイ保護ルールを追加することをお勧めします。詳しくは、「デプロイに環境の使用」を参照してください。

注: リポジトリファイル内の CNAME ファイルでは、カスタムドメインは自動的に追加または削除されません。代わりに、リポジトリ設定または API を使用してカスタムドメインを構成する必要があります。詳細については、「GitHub Pages サイトのカスタムドメインを管理する」および「GitHub Pages 用 REST API エンドポイント」を参照してください。

カスタム GitHub Actions ワークフローによる公開のトラブルシューティング

GitHub Actions ワークフローのトラブルシューティング方法については、「ワークフローの監視とトラブルシューティング」をご覧ください。