Razl-Dazl

iOSでGitHub Pagesを更新する環境のまとめ

最近のiOSはアプリが充実しているので、iPhoneやiPadでもGitHub Pages用の執筆環境を作ることができます

現時点での筆者の環境を、とりあえずここに纏めました

あくまでも運用法についての纏めになるので、細かい使用方法は省略しています


事前準備

前提としてHTMLファイルのビルド・デプロイはGitHub Actionsで自動化しています

また、SSG(Markdown文書からHTMLを生成するジェネレーター)はHugoを使用しています

管理するGitリポジトリは2つになります

  • Markdown文書やHugo用のテーマ(CSS等)を管理するリポジトリ
    • 普段はこちらだけをクローンして管理
  • Hugoで生成したHTMLファイル達を管理するリポジトリ
    • こちらは基本的に直接触れない

記事作成時のワークフローは以下のようになっています

  1. iPhoneやiPad、PCでMarkdown文書(記事)を作成する
  2. Gitリポジトリに記事をコミット、GitHubにプッシュ
  3. プッシュをトリガーとしてGitHub Actionsの処理がGitHub側で実行される
  4. GitHub Actionsによって自動デプロイされたHTMLファイル達が、Webサイトへ反映される

GitHub Actionsの設定方法は本筋ではないので割愛します

自己流のやり方は、一応こちらの記事 に書いてありますので参考に・・・(筆者はMarkdown文書のリポジトリとテーマのリポジトリも分割しているのでリポジトリが3つになっています)


Gitクライアント

筆者は必要に応じて2つのアプリを使い分けています

と言ってもほぼ基本的にMarkGitで完結します

iOS系の有名なGitクライアント(兼エディタ)と言えばWorking Copyですが、個人的にはゴチャゴチャしていてあまり好きではありません

また、クローンして新規記事をコミットするまでは無料で使えますが、プッシュもする場合は4000円くらいの課金が必要です

MarkGitは恐らく個人開発のアプリですが良いところが多数あります

  • 値段がお手頃(500円)
  • UIがシンプルで使いやすい
  • OAuthでGitHubやGitLabと連携できるので、SSH鍵の管理が不要
  • 付属エディタも最低限の機能を有する
    • シンタックスハイライト
    • Markdownのプレビュー
  • ローカルの任意のフォルダを参照できる
    • クローン時はアプリフォルダ内固定?(その後移動は可)

エディタが付属しているので、何ならこのアプリだけで作業を完結することも可能でしょう

私は他に気に入ってるエディタがあるので、Gitの機能だけを使用していますが、それだけでも課金する価値が有ります

MarkGit付属のエディタ|500
リポジトリ内のフォルダ一覧|250


エディタ

  • 先程挙げたMarkGitの機能を使う
  • Obsidian

コーディング用途のエディタは特に入れておらず、軽い修正はMarkGit同梱のエディタで済ませています

流石にそれらをiPhoneでガッツリやりたいとは思わないので・・・

文書の執筆については専らObsidianを使用しています

注意点として、iCloudまたはローカルのObsidianフォルダ内しか参照できない為、Gitクライアントを使用したい場合は外部フォルダの参照に対応したものである必要があります

Obsidianは独自機能や拡張機能(コミュニティプラグイン)も豊富ですが、シンプルにMarkdownエディタとしても優秀で、様々なOSに対応しているのでお勧めです

ここは好みが別れるところですが、Obsidianの設定ファイルをリポジトリで管理することにより、作業スペースの状態やプラグインの有効・無効状態などを保持しておくことも可能です

iPhoneでのObsidianの作業画面|200


iSH

基本的な作業はGUIで完結しますが、iSHを入れておくと便利かもしれません

筆者は以下の用途に使用しています

  • 複雑なGit操作を行いたいとき
  • シェルで動かす系のツールを使用したいとき(cwebpなど)

以下を入力するとiCloud Driveやローカルの任意のフォルダもマウント出来ますから、一通りの作業には困らないかと思います

mount -t ios . /mnt

cwebpの動作はネイティブ環境に比べたらかなり遅いですが、小さめの画像をwebpへ変換する分には許容できる範囲です

iSHのCLI画面|200


おわりに

そのうち、コーディング用のエディターも自分に合ったものを見つけたい所です

iPadとコーディングの相性があまり良くない事については、昔からずっと言われていますが、ここ数年はアプリやクラウドサービスが充実してきているので何とかなるようになってきました

サンドボックスの外へアクセスできるアプリが増えて、アプリ間の連携が容易になったのも大きいですね

MacBookを持ち運ばなくても不安にならない日は果たしてやってくるのか・・・

fin

ObsidianのメモをiCloudで同期しつつGitでバックアップする

基本的にObsidianで取ったメモはiCloudで同期させていますが、Appleのエコシステムの外にバックアップを取りたかったので何とかしました


Gitリポジトリはクラウドで同期させてはならない

大前提として、GitリポジトリをiCloud等のクラウドの同期フォルダに突っ込むことは推奨されません

クラウドの同期フォルダは別端末からの変更・保存によって意図せぬ上書きが発生することがあります

Gitリポジトリをクラウドの同期フォルダに置いた場合、意図せぬ上書きや同期の競合によって内部データが破損し、コミットの履歴が読み込めなくなる恐れがあります


作業フォルダとGitリポジトリの実態を分ける

上記の解決手段として、Gitリポジトリの実態のみをiCloudの管理下から分離するという手法を取ります

通常、Gitリポジトリの実態は作業フォルダ直下の.gitフォルダ(隠しフォルダ)内にあります

Workspace/
  ├ .git/ #この中にコミット履歴等が保管されている
  ├ example.py
  └ config.yml

まず、この.gitフォルダを任意の場所(クラウドの管理下でない、ローカルの場所)に移動させます

隠しフォルダが表示されていない場合、Macではcmd + shift + .で表示されるようになります

今回は/Users/foobar/Documents/GitAlias/Workspaceの下へ移動させたと仮定します

その後、元々.gitフォルダがあった場所へ.gitという名称のテキストファイルを作成します

Workspace/
  ├ .git #テキストファイルを作成
  ├ example.py
  └ config.yml

テキストファイルの中には.gitフォルダのパス(絶対パス)を記述します

gitdir: /Users/foobar/Documents/GitAlias/Workspace/.git

これにより、Gitリポジトリの実態を分離させた後でも、各種GitクライアントからGitリポジトリとして認識されるようになります

あとはこのWorkspaceフォルダをiCloudの同期フォルダの中へ移動させるだけです

iCloudで同期されるものは作業中の各ファイルと.gitという名称のテキストファイルのみになる為、Gitリポジトリの破損リスクは有りません

逆に言えば、ブランチの切替で作業フォルダの中身が変わってしまうと、それらもiCloudへ反映されてしまうのでブランチの頻繁な切替は推奨されません

この場合、あくまでもGitの使用目的はバックアップのみに絞るべきでしょう

変更履歴をガチガチに管理すべきソースコードたちは、このような方法でiCloud配下へ置くべきではありません


コミュニティプラグインによる自動バックアップ

さて、Gitでバックアップを取る準備はできましたので自動バックアップできるようにします

方針の概要は以下の通り

  • Gitを扱えるコミュニティプラグインを導入し、自動バックアップする
  • 自動バックアップは母艦のMacでのみ有効にする
  • iPhoneやiPadから作業する際はiCloudでのみ同期

自動バックアップをMacでのみとしたのは以下の理由によります

  • コミットの競合を避けるため
  • iOS系のアプリはサンドボックス内で動く為、.gitファイルによるGitリポジトリの実態のパス指定が難しい
  • そもそもiOS系だとObsidianの中でGitを呼び出すのが難しい(or安定して動くか分からない)

コミュニティプラグインを導入して設定するだけなので、細かい導入法は省略します

Obsidianの設定を開いてコミュニティプラグインを検索し、ソースが以下のものと一致するプラグインをダウンロードします
https://github.com/Vinzent03/obsidian-git

後はコミュニティプラグインの設定を自分好みにするだけです

  • 「Split timers for automatic commit and sync」を有効化
  • 「Auto commit interval (minutes)」と「Auto push interval (minutes)」の値を5に設定 (5分毎に自動コミット&プッシュ)
  • iPhoneやiPadでは「Disable on this device」を有効にするか、コミュニティプラグイン自体を無効化する

OSにインストールされたGitを使う

私はKeybaseの暗号化Gitにバックアップを取っているので、更にコミュニティプラグインの設定を変更しています

  • 「Custom Git binary path」の値を/usr/bin/gitに設定
  • 「Additional environment variablesの値を以下に設定
PATH=/Applications/Keybase.app/Contents/SharedSupport/bin:$PATH /usr/bin/git

手順は以上です

iCloudというエコシステムの恩恵を最大限受けつつ、Appleの管轄外へ安全にバックアップを取れるようになりました

Obsidianは独自機能に関連するファイル(canvasなど)もテキストベースのファイルとなっていますから、本当にGitと相性が良いです

UTMでdebianを手動インストールしてGNOMEを導入するまでの手順

久しぶりにUTMを触り、Debian のインストールを試みた所、 「Open in UTM」ボタンが消えていた為手動での作業が必要になってしまいました

Debianインストール

仕方ないので公式からDebian13のISOイメージを引っ張ってきます
https://www.debian.org/devel/debian-installer/

「完全なCDセット」の「arm64」または「amd64」を選択(ここはそれぞれの環境に合わせる)し、一番下の「debian-trixie-DI-rc3-arm64-netinst.iso」をダウンロードしました

UTMを起動し、新規ボタン -> 仮想化(ここもそれぞれの環境による) -> Linuxを選択
「起動ISOイメージ」の所でダウンロードしたISOファイルを選択、あとは「続ける」ボタンを押し続けてセットアップを終了

初回起動を行い、後は画面の指示に沿ってインストールしていくだけですが・・・

まずは言語選択を英語にしておくのを推奨(後に日本語が文字化けする為)
また、aptのリポジトリ設定が何故か失敗するので一旦スキップし、後で手動設定する必要がありました

インストールの完了後は仮想環境を一度シャットダウンします

CD/DVDの欄にISOイメージがセットされている場合は、これを外して空にしてから再起動します

Debian起動

これでDebianが起動できたはずですが・・・デスクトップ環境(GUI)は無くCLIでの起動となります

また、aptの設定も先ほど失敗していたので手動で行う必要があります

とりあえずaptの設定から・・・(sudoは必要に応じて)

nano /etc/apt/sources.list

設定ファイルを開いたらリポジトリを手動で追加します
trixieの部分はdebianのバージョン名ですので、各環境によって文字列が異なります

deb http://deb.debian.org/debian/ trixie main contrib non-free
deb http://deb.debian.org/debian/ trixie-updates main contrib non-free
deb http://security.debian.org/debian-security trixie-security main contrib non-free

これで最低限は動くようになった・・・はず


GNOMEインストール

目的の都合上GUIが必要なので手動で導入します

と言っても1行で終了するのでそんなに負担はありません

tasksel install gnome-desktop

インストールが完了後、再起動するとGNOMEのログイン画面が表示されるはず・・・

これでめでたく普通にDebianを使えるようになりました〜

この前まで1クリックで導入できたのに、面倒くさくなってしまいましたね

VOICEVOXサーバに他の端末からアクセスしたい

VOICEVOXはアプリを起動すると自動でサーバが立ち上がるのですが、LAN内の他の端末からアクセスするには細工が必要でした

答え

前提条件としてmacOS上での実行、アプリのバージョンは0.24.2です

条件が異なる場合は正しいパスが変わるかもしれません

ターミナルを開き、以下を入力すると他の端末からでもアクセス可能になります(既にアプリを起動中の場合は一旦終了させておく)

/Applications/VOICEVOX.app/Contents/Resources/vv-engine/run --host 0.0.0.0

ポイントは、GUIアプリを起動せずエンジンのみを起動している所です

GUIアプリを起動すると何故か引数がオーバーライドされて強制的に127.0.0.1とみなされてしまうので、エンジンのみを直接起動させる必要があります

今の時代、こういうものはLLMに質問すればすぐ解決しがちですが、今回は悪戦苦闘したので一応メモとして残しておきます

Appleシリコン搭載MacでWaydroidを動かす

MacBook Air(M3)上のmacOSにてDebianの仮想環境を構築し、更にその上でWaydroidを導入することによりAndroidアプリの実行環境を構築しました

UTM導入

仮想環境を構築するソフトウェアは複数ありますが、今回はオープンソースのUTMを使用します

App Storeでは有料配布されていますが、本家の公式ページ からは無料ダウンロードできます

インストール手順は省略

Debian環境構築

追記 「Open in UTM」のボタンが消えてしまい手動での設定が必要になりました 手順

UTMでは様々なOSを動かせますが今回はDebianにしました

「Androidを直接UTM上で動作させれば良いのでは?」と思ったそこの貴方、UTMはAndroidの実行は非推奨なのです

現に、主要なLinuxディストリビューションのイメージについてはUTMのページからダウンロード出来ますが、Androidについては削除されてしまったようで・・・

Debianの導入はUTMのページ から行うのが楽です

(UTMのインストール後に)上記ページの「Open in UTM」を押してUTMに遷移し、ダイアログの指示に従うとダウンロードと初期設定が自動で行われますので、メチャメチャ楽にDebian環境が構築できます

一応、Debian以外でもWaydroidの使用は可能ですが、

  • Waydroidの使用にはWayland環境である必要がある
  • ディストリビューションによってはDLに時間がかかる(多分Debianが一番早い)

ということでDebianをおすすめします

Waydroid導入

Debian上でターミナルを開いて

sudo apt install curl -y
curl -s https://repo.waydro.id | sudo bash
sudo apt install waydroid -y

を実行。curlさえ入っていなかったのでcurlの導入からです

Waydroid用のイメージの準備について

通常の使用法であれば、WaydroidのGUI上でイメージをダウンロードして実行となるわけですが、その手順を踏んだ場合、AppleシリコンなMac(上のUTM)では動作しません

Waydroidのissue によると・・・

既存のイメージは32bitをサポートしているがAppleシリコンでは32bitをサポートしないので、64bitオンリーなイメージを用意する必要がある、とのこと

issue内に64bitのイメージを用意してリンクを貼ってくれた人が居たので、そこからイメージを別途ダウンロードします

展開するとイメージが2つ(system.zipとvendor.zip)が出てくるのでこれを使用します

Waydroidのドキュメント に、自分でイメージを用意して起動する方法が書いてあるので、これに合わせてターミナルでいろいろ打っていきます

sudo mkdir -p /etc/waydroid-extra/images
sudo unzip system.zip -d /etc/waydroid-extra/images
sudo unzip vendor.zip -d /etc/waydroid-extra/images

# 必要に応じてzip削除
rm system.zip vendor.zip

あとは初期化処理を実行するだけで問題ない・・・はず

sudo waydroid init -f

Google Play開発者サービス を使えるようにする

Waydroidが正常起動した方、おめでとうございます

まだまだやる事が沢山残っています

最近のGoogleは未認証のデバイスを弾くようになりました

WaydroidをインストールしただけではGoogleの各サービスが使えず、ログインも出来ません

と言っても、ちゃんと解決方法が存在します

Waydroidを起動した状態で、ターミナルから以下を入力してデバイスIDを取得

sudo waydroid shell
ANDROID_RUNTIME_ROOT=/apex/com.android.runtime ANDROID_DATA=/data ANDROID_TZDATA_ROOT=/apex/com.android.tzdata ANDROID_I18N_ROOT=/apex/com.android.i18n sqlite3 /data/data/com.google.android.gsf/databases/gservices.db "select * from main where name = \"android_id\";"
android_id|XXXXXXXXXXXXXXXXXX

android_idの後に数字の羅列が出力されるので、これをGoogleの登録用フォーム に入力します

登録ボタンを押してから30分くらい経つと登録が受理され、Googleの各サービスが利用できるようになります

GApps導入

今回使用したイメージにはPlayストアが入っていなかったので、別途自力でインストールしなければなりません

waydroid_script を使用してインストールします

実行にはPython(とpip)の環境が必要なので、そちらも整えておきます

sudo apt install python3-full
sudo apt install pip

ドキュメントにも書いてありますが、依存関係のあるパッケージを別途導入

sudo apt install lzip

waydroid_scriptをgit cloneするなりzipでダウンロードするなりして、ファイルを実行

python3 -m venv venv
venv/bin/pip install -r requirements.txt
sudo venv/bin/python3 main.py install gapps

・・・で、ここで私は1度躓きました

ファイルのダウンロードが何回も繰り返されてしまうので、よくよく見てみると「MD5が一致しないのでやり直す」といった旨が出力されていました

ソースコードを眺めてみます

GAppsのダウンロード先は、waydroid_script/stuff/gapps.pyの10行目に定義されていました

dl_links = {
        "11": {
            "x86_64": ["https://sourceforge.net/projects/opengapps/files/x86_64/20220503/open_gapps-x86_64-11.0-pico-20220503.zip", "5a6d242be34ad1acf92899c7732afa1b"],
            "x86": ["https://sourceforge.net/projects/opengapps/files/x86/20220503/open_gapps-x86-11.0-pico-20220503.zip", "efda4943076016d00b40e0874b12ddd3"],
            "arm64-v8a": ["https://sourceforge.net/projects/opengapps/files/arm64/20220503/open_gapps-arm64-11.0-pico-20220503.zip", "7790055d34bbfc6fe610b0cd263a7add"],
            "armeabi-v7a": ["https://sourceforge.net/projects/opengapps/files/arm/20220215/open_gapps-arm-11.0-pico-20220215.zip", "8719519fa32ae83a62621c6056d32814"]
        },
        "13": {
            "x86_64": ["https://github.com/s1204IT/MindTheGappsBuilder/releases/download/20231028/MindTheGapps-13.0.0-x86_64-20231028.zip", "63ccebbf93d45c384f58d7c40049d398"],
            "x86": ["https://github.com/s1204IT/MindTheGappsBuilder/releases/download/20231028/MindTheGapps-13.0.0-x86-20231028.zip", "f12b6a8ed14eedbb4b5b3c932a865956"],
            "arm64-v8a": ["https://github.com/s1204IT/MindTheGappsBuilder/releases/download/20231028/MindTheGapps-13.0.0-arm64-20231028.zip", "11180da0a5d9f2ed2863882c30a8d556"],
            "armeabi-v7a": ["https://github.com/s1204IT/MindTheGappsBuilder/releases/download/20231028/MindTheGapps-13.0.0-arm-20231028.zip", "d525c980bac427844aa4cb01628f8a8f"]
        }
    }

ダウンロード先のURLと共に、ファイルのMD5が固定値で定義されていました

SourceForge上のARM版のファイル一覧 に、ソースコードの実態とともにMD5が記載されたテキストファイル(拡張子が.md5のもの)がアップされているのでそちらをDLして、正しいハッシュ値に書き換えます

私の環境では、使用するGAppsがAndroid11対応かつARM64(arm64-v8a)のものでしたので、 7790055d34bbfc6fe610b0cd263a7addを正しい値へ置き換えました

そしてmain.pyをもう一度実行・・・

無事にPlayストアが追加されました!

ここまで長かった。Appleシリコンだと一筋縄で行きませんね・・・

ブルアカが動かなかった

ブルアカをやりたかったのでダウンロードしましたが、起動しても真っ黒な画面のまま進みませんでした

ARMonARMですからそこそこのパフォーマンスで動いたらいいなぁ〜と淡い期待を抱いていましたが、動作すらせず・・・

Macでブルアカをしたいのであれば、iPhoneのミラーリングを使用するのが無難ですね

フルスクリーンに出来ないのが欠点ですが、遅延もほとんど感じないのでデイリーを回す程度であれば十分です

ただゲームが動かないとなると、MacでWaydroidを動かす意義が薄れてしまいますね・・・

また、M3チップがサポート外なので今回は試していませんが、Asahi Linux上でWaydroidを実行する手もあるので、サポートされた暁にはリベンジしようかと思います

参考

道中で記載したものは除きます

Hugo用テーマとMarkdownファイルのリポジトリを分離して管理する

Hugoでウェブサイトを生成する際、Markdownファイルはcontent/以下に配置することになりますが、このcontent/以下のファイルを別のリポジトリで管理するようにしました

分離することにより、Hugoでのビルド時には都度ファイルの配置をもとに戻す必要がありますが、ここはGitHub Actionsで自動化する事としました

元々HugoでのビルドはGItHub Actionsで行っていた為、構成はそれをベースに改良しました

元々の構成は以下↓

改良後はこちら


1つ目のWorkFlowファイル作成

元々のリポジトリからcontent/以下を削除し、こちらをテーマや設定ファイルのリポジトリとします

そして.github/workflowsの下にGitHub Actions用のYAMLファイルを作成します(ファイル名は適当でいいけどworkflow.ymlとします)

Workflowファイルで定義する処理は

  1. 自分のリポジトリをチェックアウト
  2. Markdownを管理するリポジトリを、パスを指定してClone
  3. Hugoでビルド
  4. ビルドしたファイル達を別のリポジトリへPush
name: GitHub Pages Build with Hugo

on:
  push:
  repository_dispatch:

jobs:
  deploy:
    runs-on: ubuntu-latest
    concurrency:
      group: ${{ github.workflow }}-${{ github.ref }}
    steps:
      - name: Checkout theme and config files
        uses: actions/checkout@v3
        with:
          submodules: true 
          fetch-depth: 0

      - name: Checkout Markdown files
        uses: actions/checkout@v3
        with:
          repository: username/repository_name #各自のユーザー名/リポジトリ
          path: ./content/posts # セクション単位での管理の為にサブディレクトリを指定
          token: ${{ secrets.ACCESS_TOKEN }}

      - name: Setup Hugo
        uses: peaceiris/actions-hugo@v2
        with:
          hugo-version: latest
          
      - name: Build
        run: hugo --minify
        
      - name: Deploy
        uses: peaceiris/actions-gh-pages@v3
        with:
          external_repository: username/username.github.io #各自のユーザー名
          PUBLISH_BRANCH: main
          publish_dir: username.github.io #Hugoの設定ファイルで指定したパス
          personal_token: ${{ secrets.ACCESS_TOKEN }}

私はMarkdownファイルをHugoでのセクション単位(content/以下のサブディレクトリ単位)で管理するためにpath: ./content/postsとしましたがここは各自の環境のに合わせてください

またデプロイ時のpublish_dirは、Hugoの設定ファイルのpublishDirで設定したフォルダを指定します

hugo-versionは最新になるようlatestを指定していますが、テーマの対応が追いつかない場合にビルドエラーを起こす可能性もあります 必要に応じてバージョンを固定する措置も要検討

secrets.ACCESS_TOKENはリポジトリの操作の際に必要ですが、値は後ほど定義します

このリポジトリのファイル配置は以下のようになるはず

repository/
  ├ .github/
  │ └ workflows/
  │   └ workflow.yml
  ├ content/ #中身は分離するので消す
  ├ layouts/
  ├ themes/
  ├ static/
  └ config.yml

2つ目のWorkFlowファイル作成

markdownのファイルだけを分離して新たにリポジトリを作成し、Workflowファイルを定義します

こちらでは直接処理を記述せず、1つめのWorkflowファイルを呼び出すよう定義します

GitHub ActionsではREST API経由での発火が可能ですので、それを用いて処理を記述します

name: GitHub Pages Trigger

on:
  push:
  workflow_dispatch:

jobs:
  job01:
    runs-on: ubuntu-latest
    steps:
      - name: exec REST API
        run: |
          curl \
            -X POST \
            -H "Accept: application/vnd.github.v3+json" \
            -H "Authorization: token ${{ secrets.ACCESS_TOKEN }}" \
            https://api.github.com/repos/your_username/repository_name/dispatches \
            -d '{"event_type":"workflow_dispatch"}' \
            -s \
            -w "%{http_code}"

URLのyour_username/repository_nameは各自のものに置き換えます

secrets.ACCESS_TOKENは別途定義します

またHTTPステータスコードを出力するようにしていますが、これは後のログ確認時に使用するために追加しました

repository/
  ├ .github/
  │ └ workflows/
  │   └ workflow.yml
  ├ foobar1.md
  ├ foobar2.md
  └ foobar3.md

アクセストークンを定義する

予めGitHubの設定からPersonal Access Tokenを発行し値をメモしておきます

GitHub上の各リポジトリのSettings > SecurityのSecrets and variables > Actions を選択、[New repository secret] からアクセストークンの値を定義します

Secretの欄にメモしてきた値を入力します

リポジトリ単位での設定値となるのでこれを各リポジトリで行います


実行ログの確認

各設定ファイルをCommitしてPushしたら、各リポジトリのActionsから実行結果を確認します

正常に処理を終えたら緑のチェックマークが付きます

問題があった場合はここからログを確認して原因を探ります

ちなみに、2つ目のWorkflowファイルで定義したHTTPステータスコードの出力はここで役立ちます

2つ目のWorkflowファイルではcurlの処理の実行さえ終了すれば正常終了扱いとなるため、HTTPステータスコードが401や404であった場合も緑のチェックマークが付いてしまいます

呼出先のWorkflowがうまく実行されない場合は、curlの出力結果も参考にしてみて下さい


参考

Hugoで作成したウェブサイトをGitLab Pagesで公開する

このブログ自体はGitHub Pagesで公開していますが、別ジャンルの物をGitLab Pagesで公開したかったので別途作成・・・そして色々な場所で躓いて半日くらい潰したのでメモ


GitLab用の設定ファイル作成

リポジトリ直下に.gitlab-ci.ymlを作成して内容は以下の通りにします

image: registry.gitlab.com/pages/hugo/hugo_extended:latest

variables:
  GIT_SUBMODULE_STRATEGY: recursive

pages:
  stage: deploy
  environment: production
  script:
    - hugo --gc --minify
  artifacts:
    paths:
      - public

検索すると各所で出てくるテンプレートから少し変えています

早速1行目から、通常registry.gitlab.com/pages/hugo:latestとなるところをregistry.gitlab.com/pages/hugo/hugo_extended:latestへ変更しています

Hugoで使用するテーマにSCSSファイルが含まれているとビルドに失敗するケースがあり、その対策として変更しています

またビルド時のコマンドをhugo --gc --minifyとしていますが、-gcはクリーンアップ用、--minifyは容量削減用に使用しています(どれくらい削減できるからは知らないけど・・・)

ファイル名は.gitlab-ci.ymlですのでお間違い無いように・・・筆者は最初のドットを忘れてしまいあれ動かないぞ・・・と悪戦苦闘しました

ファイル名が正しければ、VSCodeやgitlab.com上からファイルを参照したときにアイコンがキツネのマークになるはずなので、デプロイ走らないぞーって時は念の為もう一度確認しましょう


Hugoの設定ファイル調整

TOMLとかいう新参者は知らないのでここではYAML前提で進めます

config.ymlbaseURLpublishDirを調整します

baseURL: /
publishDir: public

今回はトップページをhttps://hogehoge.gitlab.io/の直下としたいので直下に指定しています

https://hogehoge.gitlab.io/blog/以下を指定したい場合はbaseURL: /blogのようになります

publishDirはGitLabの設定ファイルのpathsに対応させますのでpublishDir: publicとなります

試してはいませんが独自でpublic以外を指定した場合、デプロイに失敗する可能性が高いのでカスタマイズしないことをオススメします


Pipeline確認

設定ファイルが間違っていなければ、デプロイの処理自体は問題なく動くはずです

GitLab上の各リポジトリのBuild > Pipelines から自動ビルドが動作していることを確認します

失敗していた場合は設定ファイルを弄りましょう・・・


GitLab Pagesがそもそも有効になっているか

その後、他の端末でアクセスしようとしたらページが表示されなかった為リポジトリの設定を確認

GitLabにブラウザからアクセスして、プロジェクトの設定 Settings > General > Visibility, project features, permissionsのExpandボタンを押すとなんか設定が沢山出てくるので、Pagesの項でOnly Project Membersみたいな制限する設定になっていたらEveryoneへ修正します

リポジトリ作成時にプライベートリポジトリとして作成していると、ここが勝手に制限するような項目に設定されてしまっている可能性があるので要確認(というか筆者はそうなっていた)

ちなみに今改めて設定値を確認したら、設定値がEveryone With Accessとなっていました、表記揺れがあるようなので一字一句に拘ると躓きそうですね・・・


Webサイトのドメインがおかしい場合

いざWebサイトにアクセスしてみると勝手にリダイレクトが発動して、ドメインが通常hogehoge.gitlab.ioとなるはずが、hogehoge-gitlab-io-hogehoge-56b349062a348969d0e23582346258e02e36.gitlab.ioのような、謎のハッシュ値つきの長ったらしいものになってしまうことがある

この場合はプロジェクトのページのDeploy > PagesUse unique domainを確認すると勝手にチェックが入っているので、チェックを外して保存すると直る

ここの設定変更の確認は、少し時間を置いてからプライベートウィンドウ・または別の端末で行うことを推奨します

現状プライベートウィンドウではリダイレクトが無くなったことを確認できていますが、GitLabでログインしたままのウインドウではリダイレクトが発動してしまい、Webサイトが正常に表示されない状態です・・・
ブラウザのキャッシュ消したら表示された!めでたしめでたし


参考

GitHub Pagesとは色々使い勝手が異なるので疲れました・・・おしまい

Author@zakuro

Mastodon: 396@vivaldi.net

最近はKotlin Multiplatformにお熱です