Kory | Ryosuke Kondo

> https://github.com/GiganticMinecraft/SeichiAssist/blob/8c66a4e61e197efe54d6a84a35ae47f3c4be9fae/src/main/scala/com/github/unchama/seichiassist/listener/PlayerInventoryListener.scala#L618 > > > ここは違うんですか…? これ、実行できてないですね(これは純粋関数で、戻り値の型は `Kleisli[IO, Player, Unit]` ですので、 `Player` を渡したうえで `run` する必要があります)

c4a64c9 の時点で scalafmt を全体に強制することにしました。 後続の fdd279a で実際にプロジェクト全体に scalafmt を掛けましたが、これによりコンフリクトが発生している場合は以下の手順を実行してください： - c4a64c9 に rebase - sbt で `scalafmtAll` を実行 - 結果をコミット 上の三つの手順を実行すると、フォーマッティングによるコンフリクトは解消されるはずです。

- 「バージョンbumpアクション」を手動でポチる(`workflow_dispatch`) - **Action1**: GitHub ActionsがbumpするだけのPRを作成する(本文に適当な固定文字列 `s1` を書いておく) - リリース作業者はこれを承認する(これは自動マージされてほしい) - **Action2**: `on`: `pull_request` `closed` で、本文が `s1` なPRが来たら、 - バージョン文字列を `build.sbt` から読み取って - 対応する `master` へのリリースPRを作成する(本文に適当な固定文字列 `s2` を書いておく) - リリースPR生やし終わったら、...

なので、3つactionを用意することになる ホンマか？？？？？

これ真面目にやるの時間かかるんで一旦 branch protection を弱めました - `include administrators` → OFF - `restrict who can push to matching branches` → OFF

c4a64c9 の時点で scalafmt を全体に強制することにしました。 後続の fdd279a で実際にプロジェクト全体に scalafmt を掛けましたが、これによりコンフリクトが発生している場合は以下の手順を実行してください： - c4a64c9 に rebase - sbt で `scalafmtAll` を実行 - 結果をコミット 上の三つの手順を実行すると、フォーマッティングによるコンフリクトは解消されるはずです。

https://github.com/mikepenz/release-changelog-builder-action これかなり良さそう

これ今考えてみると、「ものを入れるためのインベントリ」にMenuって名前が付くの普通におかしいですね 似たようなものではあるけど用途が一切被らなさそうなので、StashとかProcessingStorageみたいな名前で別の機構として生やした方が筋がいいように見える

デバッグサーバーでもこれが発生していたのでサーバーログを見たんですが、onDisableが呼ばれているのがそもそもログに残っておらず「？？？？」になっています

Discordより > 技術的に可能かという疑問があって、1_1_0というJava-based migrationが存在しているうえ、一般にマイグレーションはランタイムのすべてに依存することができるんですよね マイクラサーバーをCI上で動かさないと難しい気がします（これ自体はまぁ頑張ればできそうなんですが、ライセンス周りの問題は十分慎重に解決する必要があります）