Lycolog

GitHubではWebUIからPRのマージやファイル編集をしたときにコミットに署名がつくが、これをForgejoでもやる方法。

確認環境

• Forgejo 15.0.3

やり方

基本は公式にあるInstance Commit Signingの通り。

1. 署名用のSSH鍵を作る

   ssh-keygen -t ED25519 -f forgejo
   ssh-keygen -y -f forgejo > forgejo.pub
   sudo mv forgejo* /etc/forgejo
   sudo chown git:git /etc/forgejo/forgejo
   sudo chown git:git /etc/forgejo/forgejo.pub
   

2. /etc/forgejo/app.iniに設定を足す

   [repository.signing]
   FORMAT = ssh
   SIGNING_KEY = /etc/forgejo/forgejo.pub
   SIGNING_NAME = "Example Git Instance"
   SIGNING_EMAIL = "noreply@git.example.com"
   INITIAL_COMMIT = pubkey
   WIKI = pubkey
   CRUD_ACTIONS = pubkey
   MERGES = pubkey
   

3. Forgejoを再起動する

   sudo systemctl restart forgejo.service
   

結果

対応前	対応後

コミットに署名がつき、自分のアイコンが出るようになった。

但しGitHubとは違い、Forgejoが署名したことが分かる見た目になっている。

実はGitHubでもWebUIからの修正にはGitHubの鍵で署名が行われているのだが、GitHubではUI上その区別がない。Forgejo はその区別があるため、より明確な表示になったといえる。

あとがき

コミット履歴のアイコンにForgejoがいるのが気に食わなかったので、自分のアイコンで上書きできてよかった。これで履歴の気味悪さを忘れてWebUIから気軽に治せる。

署名なしコミットは文字やアイコンが大きく、行も広くなるため、表示がしっくりこなかったので丁度よくなった。

MSYS2のGitって遅いよな～とつぶやいていたら公式から早くする方法があるよと紹介されたので、その時にやったこと。

この手順は私個人の環境に深く紐づいている。

確認環境

手順

1. 起動スクリプトを直す

    @echo off
   -set MSYSTEM=MSYS
   +set MSYSTEM=UCRT64
    set MSYS2_PATH_TYPE=inherit
    set CHERE_INVOKING=1
    C:\env\msys64\usr\bin\zsh.exe -l %*
   

2. パッケージのアップグレードを行う

   pacman -Syu
   

3. もっかいやる

   pacman -Syu
   

4. 既存のgitを消す

   pacman -S git
   

5. UCRT用のgitを入れる

   pacman -S mingw-w64-ucrt-x86_64-git
   

6. MSYS2用のGitプロンプトを廃止
   • MSYS2ではWindowsのGitを使用しており、プロンプトを出すためだけにMSYS2のGitを使っていたが、これをやめた

参考リンク

• Native Git Now Available in MSYS2
  • 倍速くらいになると書かれている

あとがき

Windows側に入ってるGit for windowsも消していい気がしてきた。まぁそもそもGit作業は今のところUbuntu実機で行っている関係もあり、滅多に使わないのだが…。ただVSCodeでパスフレーズ付きのカギを扱うときにはあった方が良さそうだし、コミット用にはあった方が良さそうな気もする。

しかし過去情報の断面を残したいがために、出来るだけ過去記事の状態を保っているが、MECEでなくなりすぎていて大変なので、そろそろWiki的な何かを作った方がいい気がしてきた。

絶対に次にフルセットアップするときにこの状態に戻せない気がしている。

ところでMSYS2公式から助言をもらえたのはFediverseをやっていたお陰な気がするので、これはとても良い出来事だったと思う。

実行環境的にMSYSはCygwinでUCRT64はWindowsネイティブで速そうなので実行環境はMSYSTEMよりUCRT64のがいいのかなとか思った。

PHP-FPMとかの設定がvhostに散らばってて一元化したかったけど/etc/nginx/nginx.confにlocationディレクティブを書くと構造上エラーになるため、再利用可能なモジュールと切り出し各vhostの設定から呼び出して解決したログ。

確認環境

• nginx/1.26.1

やり方の一例

PHP-FPMを設定する例

1. /etc/nginx/snippetsに適当な名前で.confを作る
   • 例：/etc/nginx/snippets/php-fpm.conf
2. 作ったファイルに設定を書く

   location ~ ^.+\.php$ {
     fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;
     fastcgi_index index.php;
     include fastcgi_params;
     fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
     fastcgi_param HTTPS on;
     fastcgi_param SERVER_PORT 443;
   }
   

3. 読み込みたいvhostの.confから参照する

   server {
     listen [::]:443 ssl;
     server_name hoge.example.com;
   
     # ワイルドカード証明の設定も外出ししておくと共通化できて便利
     include snippets/cert.conf;
   
     client_max_body_size 100M;
   
     root /var/www/hoge;
     index index.php;
   
     location / {
       index index.php;
       try_files $uri $uri/ =404;
     }
   
     include snippets/php-fpm.conf;
   
   }
   

UIが余りにも好みではなかったので戻した時のログ。

結論から言うと簡単に戻せた。

• 確認環境
• 手順
• あとがき
  • 切り戻した動機
  • UIが嫌なのにバージョンを上げた理由
  • どうにかして元に戻そうとした夢の跡
• あとがきのあとがき

確認環境

• バイナリから起動しているMastodon
• Mastodon本番環境をGitで管理している

手順

1. DBのロールバックを行う。34世代前に戻すと4.5.4になる

   RAILS_ENV=production bundle exec rails db:rollback STEP=34
   

2. 4.5.4時点までgit revertする
   • 参考ログ
3. Mastodonのアップグレードと同じ方法でコマンドを叩いてゆく

   sudo su - mastodon
   # Rubyのアップデート用
   cd ~/.rbenv/plugins/ruby-build
   git pull
   cd ~/live
   RUBY_CONFIGURE_OPTS=--with-jemalloc rbenv install
   # install
   bundle install
   yarn install
   # DBがアカンことがあるので叩いておく
   RAILS_ENV=production bundle exec rails db:migrate
   # いつものリビルド
   RAILS_ENV=production bundle exec rails assets:clobber
   RAILS_ENV=production bundle exec rails assets:precompile
   exit
   # 再起動
   sudo systemctl restart mastodon-web mastodon-sidekiq mastodon-streaming
   

4. 動いてれば終わり

あとがき

切り戻した動機

v4.5.4	v4.6.0

4.5系から4.6系でUIが大幅に変わること自体は知っていたが、UIの変更が余りにも多く、個人で元に戻せるレベルではなかったため切り戻しすることにした。

app/javascriptやpackage.json, yarn.lock, config/viteを戻してもバックエンドと結びついてるやつがいるようで上手くいかなかった。

以下、v4.6.0で気に入らなかった部分の一例。端的に言うと目が痛いし、ダサい。

フォロー・フォロワー一覧にある「フォローされています」が余りにもデカく、ダサすぎる。

また二枚目にある便利メニューが消えた。私はこの便利ボタンを頻繁に使用しているため非常に困った。このボタンそのものは簡単に復活させられた。

日本語翻訳がまた消えた。翻訳が消えるのはMastodonにはよくあることだが毎回翻訳キーを調べて書き換えるのが嫌になった。ここ以外にも未翻訳部分はある。

ユーザーハンドルのポップアップが変わった。前の方が良かった。説明が薄いし、Copy handleのボタンも直感的でないと思う。あと翻訳してほしい。

左に寄りすぎたタブと、直感的でなく操作に手数がかかるフィルタUI。返信を表示は今までタブとしてあったのに、4.6.0では「投稿とブースト」プルダウンをクリックし、トグルボタンを切り替えないといけない。これはとても直感的でないと思うし、そこまでして操作したくない。

自己紹介編集画面が縦長になりすぎた。自己紹介の編集画面が空白まみれになり縦長になりスクロールが必要になったうえ、更に個別の項目に編集ボタンがあり、編集しづらい。なんで初期状態で編集可能にしないのか…。

自己紹介の補足情報が一行に複数入って気持ち悪い。

自己紹介で絵文字が出ない、要素が変に改行されたりトリムされている。

ハッシュタグのコントラスト比が高く目が痛い。

スクロールバーが太くなった。スタイリッシュさが消えた。

テキスト入力欄にフォーカスが入ると枠が出るようになった。光りすぎてて目が痛い。

未読チェックが左側に出るようになった。右側に出てくれた方が押しやすい。スクショ貼るのが面倒なので以降スクショなし。

タイムラインのメニュー展開ボタンが左側に出るようになった、右側にｒｙ。

非ログインユーザーの表示が標準ではライトテーマになっており、見た目を調整するには両方のテーマを直すか、ライトテーマを消し去るしかなく、UIの保守コストが増大した。（厳密にはブラウザのテーマによって変わる）

UIが嫌なのにバージョンを上げた理由

実はこうなることは事前にある程度知っていたのだが、Wrapstodonが使いたかったからバージョンを上げたところがある。

しかし全く容認できないUIだったため切り戻すことにした。

どうにかして元に戻そうとした夢の跡

4.5系のUIを部分的に復活させた #4で、vibe codingを利用して直そうとしたものの、破綻が酷く、結局半分くらい自分で書いたが、結局変更箇所が多すぎてどうにもならなかった。

あとがきのあとがき

取り敢えずDBを壊さず、ロールバックもせず綺麗に戻せてよかった。

あるリポジトリのファイルだけを抜いてきて新たにgit管理していたが、元々のリポジトリの履歴と繋げたくなったのでやった内容。

リベースやマージを経ないためコンフリクト解消が不要でお手軽。とにかく履歴さえくっつけばいい場合に向く。

確認環境

MSYS2上のGitで確認している

前提

• 元となったリポジトリをA、リポジトリAの履歴を捨てて新しく作ったリポジトリをBとする
• どちらにもmainブランチしかないものとする

手順

1. 事故が起きると面倒なため、まず作業用フォルダを作る
2. リポジトリAをgit cloneする
3. 最新のコミットハッシュを取得する

   git rev-parse HEAD
   

4. この状態でリポジトリBをリモートリポジトリに追加する

   git remote add new リポジトリB
   

5. リポジトリBを別ブランチにチェックアウトする
6. チェックアウトしたブランチで最古のコミットハッシュを取得する。過去に連結歴のあるリポジトリでやると複数出るので注意

   git rev-list --max-parents=0 HEAD
   

7. メインブランチに戻る
8. 元となったリポジトリAに、新しいリポジトリBを繋ぎこむ。
   この時、リポジトリB側のコミットハッシュはすべて変更され、署名も消える

   git replace --graft リポジトリBの最古のコミットハッシュ リポジトリAの最新コミットハッシュ
   

一括でやるコマンド

上に書いたことをコマンドに落としただけのもの。動作確認はしていない。

mkdir temp
cd temp
git clone /path/to/old/.git
BASE_END=$(git rev-parse HEAD)
git remote add dest /path/to/new/.git
git fetch new
git checkout -b new dest/main
NEW_START=$(git rev-list --max-parents=0 HEAD)
git switch -
git replace --graft $NEW_START $BASE_END

あとがき

リベースもマージもgit mvも何もせず、異なるリポジトリを無理やり繋げたのにも拘らず、ファイル名の変更が繋がってるのが凄いと思った。

恐らくAとBで同じパスのファイルがあれば、それは同じものとして繋げてくれていると思うのだが、これは便利だ。

これによってリポジトリを分離する前の履歴が見れるようになり、過去の経緯が追えるようになったので助かった。

あとMSYS2のGitは非常にパフォーマンスが悪く重いので、こういう作業で使うと非常に遅かった。