GitLab Pagesで静的ページを公開したので、その手順を備忘録としてまとめておきます。


手順

まず、GitLab Pagesで公開するには、いくつか準備すべきことがあります。

フォルダの設定

GitLab Pagesで公開したいプロジェクト

ルートディレクトリの直下にpublicというフォルダを置いて、その中に公開に必要な全てのファイルを置くようにします。

publicフォルダ以下がウェブサイトとして公開されます。


.gitlab-ci.ymlの追加

.gitlab-ci.ymlは、GitLab CI/CDの設定ファイルです。

※Ci/CDってなーに？教えてChatGPTさん！（読み飛ばしても大丈夫）

  • CI/CDは、Continuous Integration（継続的インテグレーション）と Continuous Deployment（継続的デプロイメント）の略称です。
  • これは、ソフトウェア開発プロセスにおいて、ソースコードの変更を自動的にビルド、テスト、デプロイするための手法とツールの組み合わせを指します。
  • CI（継続的インテグレーション）は、開発者がソースコードをリポジトリにプッシュした際に、自動的にビルドやテストを行うプロセスです。

    これにより、コードの品質や互換性の問題を早期に検出し、開発者がより迅速にフィードバックを受けることができます。
  •  CD（継続的デプロイメント）は、ビルドやテストに合格したコードを自動的に本番環境にデプロイするプロセスです。

    これにより、開発者は手動でデプロイする手間やリスクを削減し、変更を素早く安全に顧客やユーザーに提供することができます。

.gitlab-ci.ymlファイルの最小構成は以下の通りです。

これをルートディレクトリ直下（publicフォルダと同じところ）に置きます。



artifacts.pathsには公開するフォルダを指定します。
GitLab Pagesでは、publicでないといけないようです。

onlyには、ジョブを実行するブランチを指定しています。
今回の場合、mainブランチにコードがpushされた時のみ、デプロイされるようになります。

scriptには、もしnodeなどで実行するスクリプトを書きます。
今回、スクリプトは使わないのですが、書かないと、
jobs pages config should implement a script: or a trigger: keyword
というエラーが発生するので、適当にecho文を書いておきます。



ここまで準備できたら、ジョブを実行するブランチ（今回の場合はmain）をpushしてみましょう。


左のメニューのBuild > Pipelines またはBuild > Jobsの中で、このようにJobがrunしているのが確認できるはずです。

GitLab PagesのBuild > Pipelines

GitLab PagesのBuild > Jobs

もしrunしていないようであれば、Build > Pipeline editorから.gitlab-ci.ymlファイルを直接いじってしまいましょう（先程のymlの内容を書き込めばOKです。左上のブランチが想定通りのものか確認するように！）

GitLab PagesのBuild > Pipeline editor


デプロイに失敗していたら、Build > Pipelinesの中で、失敗してバツが出ているところにカーソルを合わせると、エラーメッセージを確認できます。

GitLab Pagesのデプロイ確認

passedという緑色のマークが出ていたら、無事公開できています！



ページを確認する

CI/CDが登録されると、左のメニューのOperate > PagesからPages周りの設定を開くことができます。

（少し古い情報だと、Settingの中に入っていると書いてありますが、最近のバージョンアップで構成が変わったようです）

Access pagesに表示されているリンクから、デプロイしたページが開けるようになっているはずです！

GitLab PagesのPages設定画面

注意: プロジェクトをpublicにしておかないと、プロジェクトメンバーしかページを見られません！



まとめ

初回の設定に少々手間取ったものの、上記の設定さえしてしまえば、指定のブランチをpushするだけで自動デプロイしてくれるようになるので、大変便利です。

ということで、今回はGitLab Pagesで静的ページを公開する手順をまとめてみました。

かなり簡単だったので、今後も積極的に使っていきたいです。



参考