@thisis_bobobo_twitter GITBUCKET_HOMEディレクトリ（デフォルトでは実行ユーザのホームディレクトリですが環境変数等で変更可能）のとDB（ご利用の環境の場合はPostgreSQL）のバックアップで問題ないはずです。GITBUCKET_HOMEディレクトリの内容は以下のようになっています。
https://github.com/gitbucket/gitbucket/blob/master/doc/directory.md
DBで管理している内容についてはまとまったドキュメントがないのですが、リポジトリやユーザ、イシューやプルリクエストの情報などが管理されています。GitBucket上の管理コンソールからデータベースの内容を確認できます。
こちらのたけぞうさんのブログとコミュニティのプラグインでGitHubに公開されているコードを参考に手をつけてみようと考えています。
上記以外に参考になりそうな情報があれば教えて頂けないでしょうか？
https://gitbucket.github.io/gitbucket-news/gitbucket/2015/06/29/how-to-create-plugin.html
あるリポジトリのwikiの編集画面（URLは/<owner>/<repository-name>/wiki/<page-name>/_edit）を表示した際に、
Saveボタンの横に配置されている<input type="hidden" name="id" value=""/>のid（最終コミットID？）のvalueが空っぽとなってしまっており
ブラウザ画面からWikiを更新できずにいます。（TortoiseGitからのコミット&プッシュは成功しています。）
gitbucketのバージョンを4.31.2から4.35.3にアップグレードを行ったあと、この事象が発生しはじめました。
この事象は特定のリポジトリにのみ発生しており再現する条件がまだ分かっておらず、知恵を借りたいです。
上記のidが空っぽとなる場合に、どういった観点で調査すべきか、何を疑えば良いかご教示頂ければ幸いです。
@takezoe
アドバイス頂きありがとうございます。
どのバージョンから動作しないか
上記を試すにはメンテナンスのタイミングが必要なので時間がかかってしまいそうです。
取り急ぎで試せそうなことを先にやってみようかと考えており、問題の内容と直接関係がないのでダメ元感はありますが
ご教示頂いた gitbucket/gitbucket#2466 の変更分をバージョン4.35.3に取り込んで生成したwarファイルで改善されるか確かめてみようと思います。
2 replies
ver4.29.0→ver4.32.0にアップに成功（push成功）し、ver4.32.0→ver4.37.2にアップしたところ、pushに失敗し、tomcatからgitbucketにアクセスできなくなってしまいました。push時のエラーの内容は、「fatal: repository リポジトリURL not found Pushing to リポジトリURL」でした。
tomcatのlogも確認してみましたが、pushのタイミングで発生しているログはありませんでした。ブラウザからアクセスすると「404 - Not Found」となりますが、tomcatにはアクセスできています。何か原因わかりますでしょうか。
https://gist.github.com/fujifuji9999/62cf751d3cfcd482996d5f319ef6f6f5
https://gist.github.com/fujifuji9999/261c3368283dbb67effadc7d613d8393
解析ありがとうございます。
~/.gitbucket/data.mv.dbへの接続の方法は、まだやったことがないので、
https://sukkiri.jp/technologies/ides/eclipse/h2jdbc_install_web.html
こちらを参考にして確認してみます。
ちなみに、現在のdata.mv.dbのサイズを確認すると200Kbyte程度あるのですが、今回のバージョンアップよりだいぶ前に~/.gitbucket/をまるごとコピーしたものがあるのですが、それをみるとdata.mv.dbは0KBでした。これはそういうのものなのでしょうか？
定期的に（月に1度）、こちらのプラグインを参考にして自動でバックアップを取っているものがあります。DBがSQL形式で出力されています。これを使用して修復できる可能性はありますでしょうか？
https://jyuch.hatenablog.com/entry/2018/01/29/232015
~/.gitbucket/data.mv.db接続を試してみましたが、エラーとなってしまい接続できませんでした。
https://gist.github.com/fujifuji9999/81fb4648cd3792e66ec131825176d6d3
直前にバックアップしたものがあったのですが、これもdbが0byteとなってしまっていたため、戻してもgitbucketにはアクセスできるのですが、ログインできませんでした。（dbに情報がないからですね）
現状の壊れていると思われるdbを、h2のリカバリーツールを使って修復してみましたが、途中でエラーが出ていました。
https://gist.github.com/fujifuji9999/73bffebe7182655f41eda4008992fc6f
一応作成されたdbを上書きしてみましたが、やはりgitbucketにはつながりませんでした。
打つ手なしでしょうか・・・。
こちらを参考にbareリポジトリ復元を試していますが、現状dbが破損している状態だと$ git clone --mirror <SOURCE_REPOSITORY_URL>を実行してもアクセスできないためエラーとなってしまいます。
一度dbをアクセスできる状態（空）にしてから、bareリポジトリを上書きしてcloneを行えばよいのでしょうか？
その節はありがとうございました。
DBを無事に復元できましたので、DBをH2からPostgresSQLに変更しています。SQLファイルのインポートまで成功し、こちらの説明にあるSQL文をGitBucketのDatabase viewerから実行しました。
https://takezoe.hatenablog.com/entry/2016/07/16/025154
SQL文を実行すると、
SELECT setval('label_label_id_seq', (select max(label_id) + 1 from label));
は戻り値に数値が返ってきますが、
それ以外は、NULLと表示されます。これは成功しているのでしょうか？
3 replies
今、プラグインをビルドし直すとプラグインの初期化が正常実行できない現象に悩んでいます。
GitBucket本体は現在4.37.2です。（ダウンロードしたgitbucket.warをそのまま利用）
例えばデフォルトでインストールされるgistプラグイン4.22.0は動いています。
それを（テストのため念のため）アンインストールしたのち、
gitbucket-gist-plugin-4.22.0のソースを落としてそのままsbt assemblyしたものを入れると、
gistプラグインが開始できなくなります。
15:31:05.404 [Thread-5] INFO gitbucket.core.plugin.PluginRegistry - Initialize gitbucket-gist-plugin-4.22.0.jar
15:31:05.430 [Thread-5] ERROR gitbucket.core.plugin.PluginRegistry - Error during plugin initialization: gitbucket-gist-plugin-4.22.0.jar
java.lang.reflect.InvocationTargetException: null
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
といった具合です。
他のプラグインgitbucket-backup-pluginでは（initializeをoverrideしている）、
エラーは起きず起動するもののプラグイン側でoverrideしたinitializeが呼ばれない現象を確認しています。
見よう見まねで作った自作のプラグインも同様にinitializeが呼ばれなかったです。
GitBucket本体は各プラグインのinitializeを呼んでいるはずです。（改造したgitbucket.warで、plugin.initialize(...)の前後にログを置いて確認もした）
こちらの環境構成は、
gitbucket.warはWindows11上のTomcat10にデプロイしています。（上記のログはTomcatのログから取っています）
DBはPostgreSQL14.2に切り替えています。
JavaはJDK11、sbtは1.6.2です。（gist 4.22では1.5.6を指定したまま利用）
JavaをJRE8にして、サービスの再開とgistのビルドしなおしからやりなおしてみても結果は同じで、ダメでした。
以前、GitBucket4.34の頃にWin10,Tomcat9,JRE8,PSQL12といった構成で、ビルドし直した時は、正常に呼び出せていました。
gistの例ではバージョン対応されたプラグインを改変せずビルドしなおしているだけなので、
何等かこちらの環境の不整合が原因だろうと思いますが、JavaやScalaに詳しくなく対策に行き詰まってます。
このような呼び出し不整合のときに試すべき対処についてアドバイスいただけると助かります。
2 replies
対応が4.34の頃の古いプラグインがsbt.version = 1.2.8など指定しているときビルドすると、
ivyのキャッシュができていましたが、このころのgistプラグイン（4.19）が使っている1.3.12にするとivyのキャッシュはできなかったです。
ivy,mavenのローカルキャッシュ（ユーザーフォルダ内の.ivy2,.m2フォルダ）は見当たらなかったです。
以前、GitBucket4.34の頃にWin10,Tomcat9,JRE8,PSQL12といった構成で、ビルドし直した時は、正常に呼び出せていました。
と書いたのは、gitbucket-backup-pluginの話で、gitbucket-gist-pluginは当時ビルドを試してはいなかったです。
今回、改めて.ivy2は消して、GitBucket 4.34.0（自前ビルドでなくダウンロードしたリリースバイナリ）にしてみて、
JRE8,Win11,Tomcat10,H2の構成で試してみました。
JRE8を複数のディストリビュータのもので切り替えてもみました。
状況は変わらなかったです。
gitbucket-gist-pluginは、PluginRegistry.scalaの
val plugin = classLoader.loadClass("Plugin").getDeclaredConstructor().newInstance().asInstanceOf[Plugin]
での生成で失敗しているようです。
真似て作ったテストプラグインは、そこを通るものの
initializeの中でロガーから出力を出しても何もTomcatのログに残らず、
そもそもoverrideしたinitializeでsuper.initializeを呼ばなくても正常に登録が済んでいるように見えるので、
override側でなくgitbucket.core.plugin.Pluginのinitializeがそのまま呼ばれているように思えます。
（pluginIdやpluginName, description, versionsは、overrideした内容がGitBucketのPluginsページで確認できます）
JDK,JREのディストリビュータによっても違うものでしょうか。
差し支えなければ、githubで公開されているGitBucketやgistプラグインのリリースビルドで使われた
JDK,JREの入手元を教えていただくことはできますか。
2 replies
試行錯誤してみましたが当初のまま、ローカルでビルドしたプラグインに対して、次の２点が解決できなかったです。
Plugin.scalaでのPluginクラスの実装で
・newするコントローラーの中身によってnewInstanceの中でjava.lang.reflect.InvocationTargetException: nullが発生してしまう
（gitbucket-backup-pluginは問題ないが、gitbucket-gist-pluginやgitbucket-pages-pluginは上記例外が起きました）
・Pluginのoverrideしたメソッド（InitializeだけでなくおそらくはShutdownも）が呼ばれず、基底（gitbucket.core.plugin.Plugin）の実装だけが処理される
（overrideしたvarは、ローカルビルドの内容が反映される）
initializeで実行できない処理は、必要なプラグインにpostの受け口を設けて、サービス実行時に外部からcurlなどで実行することで代用させました。
しかしおかげさまでプラグインの実装やビルド状況の理解は進んだと思います。ありがとうございます。
2 replies