- IntelliJ IDEA などの統合開発環境
- JDK 8
- sbt 1.9
- Scala 2.13
- Spigot 1.12.2
- Docker
- GitHubのアカウント
- Git
最初に、Java Development Kit (JDK) 8をインストールする必要があります。 AdoptOpenJDK 1.8 のインストールを推奨します。
次に、IntelliJ IDEAなどの統合開発環境を導入します。
有料版 Ultimate Edition と機能が制限された無料版 Community Edition が2つありますが、SeichiAssist を開発する上では無料版で十分です。
ダウンロードは こちら から
Note
学生の場合は、学生ライセンスを申請することで Ultimate Edition を無料で利用できます。
- インストールする時、Gitプラグインを有効にします。
- Scala用のプラグインを導入してください。
それが終わった後、sbtの公式ページ に従ってsbtのインストールをします。
sbtがコマンドラインで使える状態でsbt assembly
を実行すると、target/build
フォルダにjarが出力されます。
Scalaはsbtによって自動的にダウンロード及びインストールされます。
SpigotサーバーのDockerコンテナを立ち上げるために、Dockerのインストールが必要です。
詳しくは Dockerの概要 及び Dockerのインストール をご確認ください。
SpigotサーバーはDockerコンテナによって提供されます。
GitHubにアカウントを登録します。 詳細な手順は有志の方の記事をご覧ください。
Warning
自分が何をしているのかわかっていないのであれば、この手順を飛ばしてください。
- VSCode + WSLで開発している
- ビルドして立ち上げたいだけ
- ランタイムの導入のコストが高いと考えている
場合は、以下のシェルスクリプトを使うと便利です。
$ rm -rf target/build # 再ビルドしたいなら既存のターゲットは削除
$ docker run --rm -it -v `pwd`:/app ghcr.io/giganticminecraft/seichiassist-builder:1a64049 sh -c "cd /app && sbt assembly"
$ sudo chown -R `whoami` target/build # docker上でsbtを実行するとrootになってしまうため権限を変える
$ cp -n docker/spigot/eula.txt docker/spigot/serverfiles/eula.txt || true
$ docker compose up --build -d
最後に、Gitのインストールも必要です。公式のガイドをご覧ください。
Warning
この手順は GiganticMinecraft のメンバーである場合は行う必要はありません。 よくわからない場合は、この注意書きを無視して先へ進んでください。
また、この手順を行うのは、一回だけです。二回目以降は、この手順を行う必要はありません。
変更を加える前に、SeichiAssistを自分の手元に「コピー」する必要があります。 最初に、GiganticMinecraftのページを開いて、画面右上にある「fork」と書かれた枝分かれしているアイコンがあるボタンを押します。
すると「Create a new fork」と書かれた画面に移動します。
いくつか入力欄がありますが、何も触らずにCreate forkを押します。
また画面が切り替わります。画面左上に書かれた文字が「GiganticMinecraft/SeichiAssist」ではなく、「(あなたのID)/SeichiAssist」になっていることを確認できたら次へ進みます。
SeichiAssistは、Gitというバージョンを管理するシステムを使っています。そのため、どうにかして自分のパソコンにSeichiAssistを自分の手元にコピーしてくる必要があります。
JetBrainsのヘルプ (英語) をご覧ください。
Warning
・この手順はコマンドラインから直接クローンした場合の手順になります。
・この手順を行うのは、一回だけです。二回目以降は、この手順を行う必要はありません。
protocol以下のファイルはgit clone
では入手できません。以下のどちらかのコマンドを実行してください:
git clone --recursive
git submodule update --init --recursive
一旦GiganticMinecraftのページへ戻って、画面上部のIssuesと書かれたタブをクリックしてみましょう。
すると画面が切り替わり、たくさんのやりたいこと (主にRedmineで承認されたもの) や、バグ報告が出てきます。
はじめはこの中からできそうなものを探すと良いと思います。初めての場合は、"good first issue"というラベルがつけられた中から探すのがおすすめです。 ここから飛べます。
IntelliJ IDEAの設定でフォーマットに scalafmt
を使う
Editor
>Code Style
>Scala
でFormatter
をScalafmt
に変更Reformat on file save
にチェックを付ける
- developというブランチ (セーブデータのスロットのようなもの) を元に、新しいブランチを作ります。
- 必要な変更を加えてファイルを保存します
- コミット (Gitに対するセーブ) します。コミットする時、メッセージを書くように求められます。コンベンショナルコミットという、メッセージの書き方を推奨しています。わからなければ、今は飛ばしても大丈夫です。
- メッセージの1行目には変更した点の大まかな内容を書くように心がけてみてください。
- 1行目は45文字以内で書くことを推奨します。
- コンベンショナルコミット:1行目は「変更の区分」、半角コロン、半角スペースで始める方法を推奨しています。
- 新しい機能を実装したときは
feat: [大まかな内容]
とします。 - バグを修正したときは
fix: [大まかな内容]
とします。 - ドキュメントを触ったときは
docs: [大まかな内容]
とします。 - GitHub Actionsを触ったときは
ci: [大まかな内容]
とします。 - リファクタリングしたときは
refactor: [大まかな内容]
とします。 - テストを書いたときは
test: [大まかな内容]
とします。 - scalafmtやscalafixを反映したときは
style: [大まかな内容]
とします。 - パフォーマンスを改善したときは
perf: [大まかな内容]
とします。 - その他のコード品質に関わらない変更をしたときは、
chore: [大まかな内容]
とします。
- 新しい機能を実装したときは
- 発展的な内容:コンベンショナルコミットにおいて複数の種別に該当する場合、引き返して複数のコミットに分割することが推奨されています。
- メッセージの2行目以降は、より詳しい内容を書けます。必要に応じて記入してください。
- メッセージは日本語か英語で書くことを推奨します。
- メッセージの1行目には変更した点の大まかな内容を書くように心がけてみてください。
- 良くなるまで繰り返します
SeichiAssistは手元でデバッグできる環境を整えています。環境を立ち上げるためには、Dockerが必要です。
Linux環境では、./prepare-docker.sh
、Windowsではprepare-docker.bat
を実行することで
デバッグ用のBungeecordとSpigotの環境を構築することができます。
また、第1引数として以下のようにupdate-gachadata
を指定すると、ガチャ景品データがダウンロードされ、開発環境のデータから置き換えられます。
※初回起動時にはgachadataテーブルが空の状態になっているので、ガチャ景品データが必要な場合はオプションを付けずに一度起動したあとに、update-gachadata
オプションを付けて起動してください。
※初回起動時にupdate-gachadata
を指定するとFlywayによるマイグレーションと競合し、起動することができません。(2023/07/27時点)
./prepare-docker.sh update-gachadata
サーバーやDB等を停止する場合、 docker compose down
を実行してください。
なお、SeichiAssistがJDK 8以外でコンパイルされた場合は、実行時にエラーとなります。必ずJDKのバージョンを揃えるようにしてください。
DockerマシンのIPアドレス(Linux等ならlocalhost
)をDOCKER_IP
とします。
docker
により各サービスが起動したら、マルチプレイヤーのメニューでDOCKER_IP
へと接続できます。
また、DOCKER_IP:8080
へとWebブラウザでアクセスすることで、phpMyAdminを介してデータベースを操作できます。
自分のアカウントに管理者権限(OP)を与える時など、Spigotのコンソールにアクセスする場合は、
spigota
または spigotb
のコンテナにアタッチする必要があります。
アタッチするには docker attach [CONTAINER_NAME]
を実行します。
コンテナを指定する際に使用するIDはコマンドプロンプトで docker ps
を実行すると seichiassist_spigotb_1
のような形式で表示されます。
コンソールからは CtrlキーとCキーを同時押しすることで出ることができます。サーバーは停止されません。
初めてデバッグ環境のSpigotに接続した際にスポーンするワールドは整地ワールドではないため、そのままブロックを破壊しても整地レベルは上昇しません。
整地ワールドを作成する場合、OP権限を付与したプレイヤーかアタッチしたコンソールからコマンドで mvcreate world_SW normal
を実行します。
整地ワールドへ行くには、コマンドで mvtp world_SW
を実行します。
さあ、いよいよ反映の時間がやってきました。
まずは手元でsbt scalafixAll
をします。次にsbt scalafmtAll
をします。
その後、自分の手元から自分のGitHubアカウントへ内容を反映します。
次に、自分のGitHubアカウントにあるSeichiAssistを開いて、変更を依頼する手続き (Pull Request) の準備画面へ移動し、右上のCreate pull requestと書かれたボタンを押すとこのような入力欄が表示されます。
close #
----
### このPRの変更点と理由:
### 補足情報:
(一部省略)
書くべき主な内容の説明はコメントに記載されています。
どれも必須ではありませんが、メンテナたちにどんな変更をしたのか正確に伝えるためにもなるべく書くことを心かけるといいでしょう。
close #
- プルリクエストと対象のIssueを紐付ける事ができます。
- そのプルリクエストに関係し、なおかつマージ後に自動でクローズしたいIssueの番号を指定してください。
- 複数のIssueを紐付ける場合は
close #1, close #2
と繰り返し指定します。 - 詳細: キーワードを使用してPull RequestをIssueにリンクする - GitHub Docs
このPRの変更点と理由:
- このプルリクエストで行った変更点とその理由を記述します。
- 自明な場合は書く必要はありませんが、なるべく書くようにします。
補足情報:
- その他、メンテナたちに伝えたい事があれば自由に書いてください。
一通り書き終わったら、長い場所の右下にある「Create pull request」と書かれたボタンを押してください。
Pull Requestが作成されたら、GitHubのサーバーでコンパイルやファイルのチェックが自動的に始まります。 また、確認できる人 (主に@kory33、@rito528、@KisaragiEffective、@Lucky3028)が方向性が正しいかどうかレビューを行います。それまでは優雅に紅茶を飲んだり踊ったりして待つことができます。
SeichiAssistでPull Requestが受け入れられる (マージされる) には、下の条件をすべてクリアする必要があります。
- コンパイルやファイルのチェックがすべてエラーなく終わる
- コンパイル
- scalafix - エラーになった場合は
sbt scalafixAll
をしてください - scalafmt - エラーになった場合は
sbt scalafmtAll
をしてください
- 誰かから変更を承認してもらう
条件がすべてクリアされると、Pull Requestがマージ (変更依頼手続きが完了) されます。
マージされた後、自動的にデバッグサーバーへの反映手続きが始まります。Discordで進捗を確認できます。 通常、デバッグサーバーへの反映は数分程度で終わります。 デバッグ環境へは、以下の手順で接続できます。
- Minecraft Java Editionで
play-debug.seichi.click
に接続 - Tキーでチャットを開く
/server deb112
と入力してEnter
を押す
自動リリースはSeichiAssistのプログラムの部分のみ行われます。より正確に言うのであれば、jar以外の自動リリースは未対応です(config.yml
など)。運営チームへ更新を依頼する必要があります。
この問題点があるため、各サーバーや環境で共通で構わないパラメータはconfig.yml
を読まず、コードへの直接実装を推奨します。
本番サーバーへの反映は通常GitHub ActionsでPull Requestを作成し、それをマージすることで行います。
- GitHub Actionsのタブへ移動します。
- 画面右の「Run workflow」を押します。
- しばらくすると
master <- develop
のPull Requestが作成されます。 - 本番サーバーへ反映したいタイミングでマージします。
- マージした後、朝4時の再起動で変更が反映されます。
緊急を要する場合は、hotfix-*
ブランチを作成し、そのブランチからmaster
ブランチへ向けてPull Requestを作成してください。
develop
ブランチへの直プッシュは、CIによるチェックが事後となってしまうため避けてください。