Test / test (push) Successful in 2m1s
Release / gates (push) Successful in 1m57s
Release / build (amd64, freebsd) (push) Successful in 1m26s
Release / build (amd64, linux) (push) Successful in 1m30s
Release / build (arm64, freebsd) (push) Successful in 1m28s
Release / build (arm64, linux) (push) Successful in 1m49s
Release / build (loong64, linux) (push) Successful in 1m30s
Release / build (riscv64, linux) (push) Successful in 1m29s
Release / release (push) Successful in 41s
Assisted-by: GLM 5.3 Flash
130 lines
6.0 KiB
Markdown
130 lines
6.0 KiB
Markdown
# Contributing
|
|
|
|
Contributions to **nuntius** are governed by the Contributor terms
|
|
below; submitting one means you accept them.
|
|
|
|
## Contributor terms
|
|
|
|
1. This project belongs to its owner alone. The owner decides what is
|
|
accepted, in what form and when; the decision is final and needs no
|
|
justification.
|
|
2. By submitting a contribution you assign to Petr Balvín
|
|
<opensource@petrbalvin.org> all present and future copyright and
|
|
related rights in it, worldwide, for the full term of the rights,
|
|
with the right to relicense and sublicense without restriction,
|
|
including under proprietary terms.
|
|
3. Where that assignment is not effective, it counts as a perpetual,
|
|
irrevocable, royalty-free licence with the same scope.
|
|
4. To the fullest extent permitted by law, you waive any right of
|
|
attribution and integrity in the contribution. The project names no
|
|
contributors and keeps no credits list.
|
|
5. By submitting you represent that the work is yours and that you
|
|
hold the rights to assign it as above.
|
|
|
|
## Development setup
|
|
|
|
Requirements: Go 1.27.1 (the version recorded in `go.mod`), and
|
|
[just](https://github.com/casey/just) for the recipes. The race detector in
|
|
`just gates` needs a C compiler, so gcc must be installed. nuntius builds
|
|
and tests on Linux and FreeBSD.
|
|
|
|
```sh
|
|
git clone https://sourcedock.dev/petrbalvin/nuntius.git
|
|
cd nuntius
|
|
just build
|
|
just test
|
|
```
|
|
|
|
The automated suite is hermetic: the SMTP tests run against in-process fake
|
|
servers and the storage tests against temporary directories, so no network
|
|
or SMTP account is needed to develop. A local SMTP account only matters for
|
|
manual end-to-end checks.
|
|
|
|
## Workflow
|
|
|
|
1. Branch from `development`. Never commit directly to `main`, which is release-only.
|
|
2. Commit in [Conventional Commits](https://www.conventionalcommits.org/) form:
|
|
`type(scope): description`, subject line only, imperative mood, lowercase after the
|
|
colon, no trailing full stop. Allowed types: `feat`, `fix`, `docs`, `style`,
|
|
`refactor`, `perf`, `test`, `chore`, `ci`, `build`, `revert`.
|
|
3. One logical change per commit. A refactor, a behaviour change and a formatting pass
|
|
are three commits, never one.
|
|
4. Record every user-visible change in `CHANGELOG.md` under `## [development]`.
|
|
5. Add or update tests. Coverage stays at 80 percent or more; it is a hard gate.
|
|
6. Update the documentation when the public API, the configuration or the behaviour
|
|
changes: `README.md` for the overview, `docs/CONFIGURATION.md` for keys,
|
|
`docs/API.md` for endpoints, `docs/ARCHITECTURE.md` for structure,
|
|
`docs/DEVELOPMENT.md` for tooling.
|
|
7. Never commit while `just gates` is red; run it locally first.
|
|
8. Open a pull request against `development`.
|
|
|
|
Releases are cut by merging `development` into `main` and tagging `vX.Y.Z`. The release
|
|
workflow builds the assets and publishes the release and its notes.
|
|
|
|
## Code style
|
|
|
|
`gofmt` and `go vet` run through `just fmt` and `just vet`, with zero diff and zero
|
|
warnings tolerated. `just vet` also runs `go fix -diff`, so modernisations are part of
|
|
the gate and not a follow-up. `just gates` is the definition of done in one command,
|
|
and the recipe file names what it contains. Errors are checked explicitly, wrapped as
|
|
`fmt.Errorf("context: %w", err)`, and nothing panics outside `main`. Error messages
|
|
are English, lowercase, with no trailing full stop, and SMTP credentials or full
|
|
request bodies never appear in a log line.
|
|
|
|
New source files open with the project's two-line licence header, whose SPDX
|
|
identifier matches `LICENSE`. Configuration files, workflows and dotfiles do not carry
|
|
it.
|
|
|
|
## AI contribution policy
|
|
|
|
AI tools are welcome as productivity aids and are a normal part of modern software
|
|
development. What matters is that the contribution stays understandable, reviewable and
|
|
genuinely useful.
|
|
|
|
- **Disclose the assistance.** If AI helped draft any part of a commit, issue, pull
|
|
request or review, say so.
|
|
- **Commit messages carry exactly one trailer**, on the line after the subject:
|
|
|
|
```
|
|
Assisted-by: MODEL
|
|
```
|
|
|
|
Name the model that did the work, spelled the way its maker spells it, for example
|
|
`GLM 5.3`, `DeepSeek V4.1 Flash` or `Qwen 3.8 Flash`. No `Co-Authored-By`, no `Signed-off-by`,
|
|
no other trailers, and no prose: the trailer is the disclosure.
|
|
- **Issues and pull requests** attribute the assistance in a comment, for example
|
|
`_Assisted-by: GLM 5.3 Flash_`. It does not belong in the pull request description.
|
|
- **Take responsibility.** You are accountable for the accuracy, completeness and
|
|
intent of everything you submit, whether or not AI produced it.
|
|
- **Review before marking ready.** Read the diff carefully, run it locally, and add the
|
|
tests it needs. Do not mark a pull request ready until you can defend every change in
|
|
it.
|
|
- **Quality over quantity.** Contributions that look like un-reviewed output, or whose
|
|
author cannot engage substantively during review, may be closed.
|
|
- **Preferred models.** Prefer open-weight models with transparent training data and
|
|
minimal output filtering.
|
|
|
|
AI assists. It does not replace judgement.
|
|
|
|
## Continuous integration
|
|
|
|
Workflows live in `.gitea/workflows/` and run on the project's own runners:
|
|
|
|
| Workflow | Trigger | What it does |
|
|
|---|---|---|
|
|
| Test | push or pull request to `development` | build, format check, vet, modernisation, the test suite with the coverage floor |
|
|
| Race | dispatched by hand | the suite under the race detector, as a second opinion after the local gate |
|
|
| Release | a `v*` tag | the same gates as Test, then the matrix build, the proven version and the release itself; the race detector runs locally in `just gates` before the tag is cut |
|
|
|
|
The local equivalent is `just gates`, which is the same set plus the race detector.
|
|
|
|
## Reporting bugs
|
|
|
|
Open an issue at <https://sourcedock.dev/petrbalvin/nuntius/issues> with the
|
|
version (`bin/nuntius --version`), the operating system and architecture, the
|
|
exact command or request, the full output, and the expected against the
|
|
actual behaviour.
|
|
|
|
**Security issues do not go in the issue tracker.** Report them as
|
|
[SECURITY.md](SECURITY.md) describes.
|