Files
kst4contest/.agents/skills/kst4contest-change/references/testing-build-release.md
T

101 lines
2.1 KiB
Markdown

# Build, tests, static analysis and release safety
## Maven
Use the repository Maven wrapper.
Windows:
```text
.\mvnw.cmd test
.\mvnw.cmd package
```
Run narrower tests first when possible.
## Important Surefire behaviour
The project has used:
```xml
<testFailureIgnore>true</testFailureIgnore>
```
Therefore an exit code of zero is not sufficient evidence that all tests passed.
Always inspect:
- test counts;
- failures;
- errors;
- skipped tests;
- Surefire report output when necessary.
State exact results in the completion report.
## PMD and SpotBugs
PMD and SpotBugs are integrated, but their findings have historically not always failed the build.
Do not say "static analysis clean" unless the relevant reports/output were actually checked.
## Packaging
The build contains packaging/module-list consistency logic.
Changes involving modules, JavaFX modules, jpackage or `module-info.java` must check:
- `pom.xml`;
- `packaging/` helpers;
- module requirements;
- packaging verification output.
Do not manually update only one copy of a generated/synchronized module list.
## Website
The website is Eleventy-based and has Node tests.
Inspect `website/package.json`, `website/test/` and current scripts before choosing exact commands.
Historical website validation included Node tests for generated version/update information.
## Documentation build
GitHub Actions generates documentation/PDF and site artefacts.
A local code build does not prove documentation/site CI will pass.
## Versioning
Do not change project version, semantic version, update feed, tag or release metadata unless explicitly requested.
## Git
Each of these needs separate authorization:
- stage;
- commit;
- push;
- PR;
- merge;
- tag;
- release.
When asked to commit, use a concise English commit message.
Do not stage unrelated files.
## Release communication
When a release is explicitly in scope, check:
- current changelog;
- GitHub release/tag;
- website download/update feed;
- documentation;
- HamRadioOnline download/manual destinations;
- any SourceForge publication workflow currently used.
Do not assume an older deployment pipeline is still active.