Files
Radixor/docs/reports.md
Leo Galambos e7800b29c9 feat!: modularize stemmer models and release infrastructure
Move bundled stemmer dictionaries from the core artifact into independently
versioned model modules. Add model discovery and explicit model-loading APIs,
a standard model aggregate, a model BOM, and dedicated model and catalog
release workflows.

Add full PoliMorf integration, model provenance and licensing validation,
streaming model-input verification, strict dependency verification, consumer
resolution tests, Configuration Cache compatibility, and expanded JMH,
quality, documentation, and release checks.

Upgrade the CycloneDX and JMH Gradle plugins and remove Gradle 10 and Java
compiler deprecations.

BREAKING CHANGE: The core Radixor artifact no longer contains bundled stemmer
dictionaries. Applications must add the required model artifacts, the standard
model aggregate, or model dependencies managed through the Radixor model BOM.
2026-07-22 23:33:28 +02:00

4.1 KiB

Reports and Published Build Artifacts

Radixor publishes durable build outputs to GitHub Pages from qualifying runs of .github/workflows/pages.yml.

The workflow builds maintained MkDocs documentation and the generated model catalog from the staged source tree under build/mkdocs-source/. It then merges the rendered site into the separate gh-pages publication worktree while preserving builds/. The main branch stores neither generated Markdown nor rendered site output. The publication retains the ten newest numbered report sets and maintains builds/latest/ as a stable alias.

This page is the central entry point for published project artifacts, including build summaries, API documentation, test and quality reports, benchmark outputs, and software composition materials. It is intended both for routine project inspection and for linking stable report surfaces from external references such as the README, release notes, or development workflows.

Stable entry points

The following links are the primary stable locations for the most recent published build outputs:

Use builds/latest/ when you want the current published report surface. Use builds/ when you need to inspect or compare retained historical runs.

API and developer documentation

These reports are primarily useful when reviewing the published API surface and generated developer-facing documentation:

Verification and code quality reports

These reports describe the outcome of core verification and static-analysis stages for the latest published build:

Together, these reports provide the most direct published view of functional correctness, static quality signals, coverage, mutation resistance, and dependency-level security review outputs.

Software composition artifacts

These artifacts expose the published software bill of materials for the latest build:

They are useful for dependency inspection, downstream integration, compliance-oriented workflows, and artifact traceability.

Benchmark outputs and badge metadata

These resources expose benchmark results and generated badge metadata derived from the latest published build. JMH benchmark reports are published as TXT and CSV files; the historical Porter comparison badge is no longer generated.

The benchmark outputs provide direct access to the published JMH result files. Coverage and mutation badge metadata endpoints are intended for status surfaces such as the project README or other generated dashboards.

Practical usage

In most cases, the recommended entry path is:

  1. start with the Latest build summary,
  2. open the specific report category relevant to your task,
  3. use Browse historical build reports when historical inspection is needed.