Skip to main content

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

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

Who can use this feature

People with admin or maintainer permissions for a repository can configure a publishing source for a GitHub Pages site.

GitHub Pagesは、GitHub Free及びOrganizationのGitHub Freeのパブリックリポジトリ、GitHub Pro、GitHub Team、GitHub Enterprise Cloud、GitHub Enterprise Serverのパブリック及びプライベートリポジトリで利用できます。 詳細については、「GitHub's products」を参照してください。

公開元について

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

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

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

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

ブランチからの公開

  1. 公開元として使用するブランチがリポジトリ内に既に存在していることを確認します。

  2. GitHub Enterprise Cloudで、サイトのリポジトリにアクセスしてください。 1. リポジトリ名の下の [ 設定] をクリックします。 リポジトリの設定ボタン

  3. In the "Code and automation" section of the sidebar, click Pages.

  4. [ビルドとデプロイ] の [ソース] で、 [ソースからのデプロイ] を選択します。

  5. [ビルドとデプロイ] の [ブランチ] で、 [なし] または [ブランチ] ドロップダウン メニューを使用し、公開元を選択します。

    公開元を選択するドロップダウン メニュー

  6. 必要に応じて、ドロップダウンメニューで発行元のフォルダを選択します。 公開ソースのフォルダーを選択するドロップダウンメニュー

  7. [保存] をクリックします。 公開ソースの設定の変更を保存するボタン

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

: ブランチから公開しようとしていて、サイトが自動的に公開されていない場合は、管理者アクセス許可と検証済みの電子メール アドレスを持つユーザーが公開ソースにプッシュしていることを確認してください。

公開ソースとして任意のブランチの 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 Pages サイトを公開する機能はベータ段階であり、変更される可能性があります。

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

  1. GitHub Enterprise Cloudで、サイトのリポジトリにアクセスしてください。 1. リポジトリ名の下の [ 設定] をクリックします。 リポジトリの設定ボタン

  2. In the "Code and automation" section of the sidebar, click Pages.

  3. [ビルドとデプロイ] の [ソース] で、 [GitHub Actions] を選択します。

  4. GitHub Enterprise Cloud により、いくつかのスターター ワークフローが提案されます。 サイトを公開するワークフローが既にある場合、この手順をスキップできます。 それ以外の場合、GitHub Actions ワークフローを作成するオプションのいずれかを選択します。 カスタム ワークフローの作成に関する詳しい情報については、「サイトを公開するカスタム GitHub Actions ワークフローの作成」を参照してください。

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

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

GitHub Actions の詳しい情報については、「Actions」を参照してください。

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

  1. リポジトリの既定のブランチへのプッシュがある場合、または既定のブランチを対象とする pull request のオープン、再オープン、または更新が行われるたびにトリガーされます。
  2. actions/checkout アクションを使用してリポジトリの内容をチェックアウトします。
  3. サイトで必要な場合、静的サイト ファイルをビルドします。
  4. actions/upload-pages-artifact アクションを使用して静的ファイルを成果物としてアップロードします。
  5. ワークフローが既定のブランチへのプッシュによってトリガーされた場合、actions/deploy-pages アクションを使用して成果物をデプロイします。 ワークフローが pull request によってトリガーされた場合、この手順はスキップされます。

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

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

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

GitHub Actions ワークフローのトラブルシューティング方法に関する詳しい情報については、「監視とトラブルシューティングについて」を参照してください。