Skip to content

Latest commit

 

History

History
39 lines (22 loc) · 2.05 KB

File metadata and controls

39 lines (22 loc) · 2.05 KB

Contributing

Thanks for considering contributing. This document covers how to get a change built, tested, and merged.

Getting started

Fork the repository, clone your fork, and make sure you have Java 21 installed. Then:

./gradlew build

This compiles every module, runs Checkstyle and PMD, and (where present) runs the test suite. Building against net.eternalempires:* dependencies requires GitHub Packages credentials even for public packages — either set GITHUB_TOKEN to a personal access token with read:packages scope, or point your build.gradle at maven-proxy (https://packages.eternalempires.net), which doesn't require one.

Branching

Base your branch on develop and open your pull request against develop, not main. main always reflects the latest release and only accepts pull requests coming from develop — this is enforced by CI, so a PR opened from a feature branch straight into main will fail the branch check automatically.

Commit messages

Commits are checked against Conventional Commits on every pull request:

type(scope)?: description

type is one of feat, fix, chore, docs, style, refactor, perf, test, build, or ci. scope is optional. Example: fix(paper): correct balance rounding in /pay.

Code style

Checkstyle and PMD run on every pull request and report issues inline; ./gradlew build runs the same checks locally so you can catch them before pushing. If a module has tests, run them with ./gradlew test and add tests for new behavior where it makes sense.

Pull requests

Keep pull requests focused on a single change — it's easier to review and easier to revert if something goes wrong. Describe what changed and why in the description; if the change is user-facing (a new command, a config option), mention that explicitly.

License

By contributing, you agree that your contribution is licensed under the terms in LICENSE, including the grant described there.