Thanks for contributing to Anvil.
- Security issues: do NOT open a public issue or discussion. See SECURITY and email us at
security@exploit.org. - Questions / support: use GitHub Discussions (Q&A).
- Bugs / actionable work: use GitHub Issues (only after you can describe a reproducible problem).
- Design proposals / larger changes: start in Discussions first (Ideas), then open an issue/PR.
Before opening an issue:
- Search existing issues/discussions.
- Test on the latest release (or
mainif you can).
Include:
- Expected vs actual behavior
- TKeeper version / commit SHA
- Minimal reproduction steps (copy-pasteable)
- Logs/stack traces (don't forget to remove secrets if present)
- Environment (OS, JDK)
If you can provide a minimal failing test, even better.
- If your change affects behavior, add or update an integration test. See integration tests
- If you're not sure whether something is “behavioral”, assume it is and add the test.
- Prefer small PRs with one clear purpose.
- Add tests for behavior changes when practical.
- Don’t mix large refactors with bug fixes. Keep fixes small and reviewable.
- Keep public API changes explicit.
Use clear messages. Conventional Commits are recommended:
fix: ...feat: ...chore(deps): ...test: ...
A PR should include:
- What changed (short summary)
- Why it changed (rationale)
- Tests added/updated (or why not)
- Notes on compatibility and security impact (if applicable)
By contributing, you agree that your contributions will be licensed under the project Apache 2.0 license.