Can the validation artifacts be built?
JVM jars, the BOM, Android main sources, the Wasm distribution, and the smoke-line consumer.
Development · release · transparency
From pull request to published release.
HDCharts moves from a focused pull request to a tested snapshot and a verified public release, with the important checkpoints kept visible.
release-flowrelease flow
A change moves through checks, snapshots, and public release.
CORE LIBRARYHDCharts · charts
Kotlin Multiplatform library, demos, tests, and release orchestration.
↗PUBLIC SITEcharts-docs
Versioned wiki, API links, release notes, metadata, demos, and the docs application.
↗INTERACTIVE WEBcharts-playgroundA browser playground built with the Charts source and published with snapshot metadata.
↗VISUAL TOOLINGcharts-gif-recorderA Gradle plugin used by Android documentation scenarios to record and validate animated baselines.
↗LIBRARY OUTPUTMaven Central
Stable and snapshot Kotlin Multiplatform modules and the BOM.
↗STATIC DELIVERYS3 + CloudFrontVersioned API references, demos, playground files, metadata, and Android APKs.
↗SITE DELIVERYVercelBuilds and serves the Next.js documentation application from charts-docs.
↗AUTOMATIONGitHub ActionsCoordinates pull requests, snapshots, releases, and security scans.
↗FoundationKotlin MultiplatformCompose MultiplatformGradle + AxionAndroid · iOS · JVM · Wasm
01
Workflow chart
Pull request validation
Every pull request first checks whether it needs the full validation path. Documentation-only changes keep their required checks without running expensive work.
STARTPrepare the PR
Check out the revision, detect changed paths, and run workflow self-tests.
DECISIONCode or build changes?
Docs, release notes, GIF baselines, scripts, and Markdown are treated as lightweight paths.
NO · documentation-only
SKIP EXPENSIVE WORKDocs-only no-op
Assemble, compile, lint, and tests report lightweight success without allocating their normal work.
CONTINUERequired check remains visible
The PR can still satisfy the expected check contract.
YES · code or build change
PARALLEL CORE CHECKSAssemble · compile · lint · test
The four reusable checks run together as the core PR gate.
CONTINUEPR Core Checks
The final gate rejects any failed, cancelled, or skipped required result.
Alongside core checksIndependent policy lanes
API POLICYCheck the public API
The lane runs for code changes and breaking-change label events.
NO
SKIPAPI compatibility not requested
YES · compatible
PASSPublic API is compatible
BREAK DETECTED + LABEL
ACKNOWLEDGEDDocument and acknowledge the break
Keep the breaking-change label when the API checker flags an intentional public API incompatibility, update release notes and affected docs, then review the API baseline PR created after merge. See the release migration notes for examples of the required call-site changes.
POLICY MISMATCH
STOPFix the API policy mismatch
Add the label for an intentional break, remove a stale label, or fix the compatibility task error before merging.
OPTIONAL GIF WORKFLOWrun-gif-validation label present?
Opened, updated, or label changes can request the visual validation job.
NO
SKIPNo GIF job requested
This is informational and not a required branch-protection check.
YES
ANDROID EMULATORRecord and compare GIF baselines
The job stays outside the required core gate, but its report and generated GIFs are uploaded for review. See the chart examples.
MATCH
PASSGIF baseline matches
MISMATCH
REVIEWFix the visual change or update the baseline
Download the validation artifacts. Fix unintended output; for an intentional change, update the matching file in gif-baselines/ and rerun validation.
What gets tested
The checks have distinct jobs.
CI does not treat every validation as the same kind of signal. Each lane protects a different part of the library and its release contract.
Do all supported targets compile?
Kotlin/JVM, Kotlin/Wasm, Android main sources, and the smoke-line consumer compile path.
Does behavior hold on each surface?
JVM tests, Android emulator tests, Wasm browser tests, iOS simulator tests, and Android screenshot validation.
Did the public contract change?
Binary and source compatibility are compared with the stored release baseline. Intentional breaks need the breaking-change label.
Do visual motion baselines still match?
An opt-in Android emulator job records and compares GIF baselines. It stays outside the required core gate.
Is the code scanned regularly?
A scheduled monthly scan covers Actions, Java/Kotlin, and JavaScript/TypeScript security analysis.
02
Workflow chart
Snapshot publishing
Snapshots keep the latest development build available. Scheduled runs publish only when relevant changes are present.
DECISIONRelevant changes in the last 24 hours?
Docs and Markdown-only changes are ignored, while release notes remain relevant.
NO · scheduled run
STOP CLEANLYNo snapshot published
No recent changes, or only ignored paths, ends the run without publishing.
YES · or manual run
CONTINUEPrepare the snapshot
Axion resolves the version. If the current version is not a snapshot, publication ends here.
SOURCE + DOCSSync snapshot context
Mirror release notes and GIF baselines into charts-docs, write snapshot-manifest.json, and push only when content changed.
STATIC ASSETSPublish snapshot API, demo, playground, and metadata
The static assets are published for the development version.
MAVENPublish the snapshot modules
Signed snapshot artifacts are published to the Maven snapshot repository.
PARALLEL FOLLOW-UP
ANDROIDBuild and upload Android snapshot
Assemble the release APK against the published snapshot dependency and upload it to the docs static storage.
PARALLEL FOLLOW-UP
ANNOUNCEUpdate rolling GitHub prerelease
Publish release-note highlights and comment with documentation and Maven links.
03
Workflow chart
Stable release
A stable release is a manual, approval-gated promotion of a tested snapshot. It validates the code, artifacts, and documentation before publishing.
PREPAREResolve and validate the release
Axion resolves the SemVer and release readiness is checked before publishing.
VERSION / TAG
STOPVersion or tag validation fails
An invalid version or an existing release tag blocks the flow.
API AUDIT
CONTINUECompatible or acknowledged API change
No previous release skips the audit. An intentional break continues with a warning.
API AUDIT
STOPUnexpected API audit failure
A non-compatibility failure, or an unlabelled incompatible API, blocks release.
VERSION CHECKAre the snapshot and release metadata aligned?
Existing docs entries and the snapshot metadata must agree with the release version before promotion.
NO
STOPMissing or mismatched release metadata
The release cannot promote unrelated or stale documentation.
YES
READYRequest production approval
The release source and snapshot are now aligned.
GATERelease Approval environment
Publishing does not begin until the protected production approval completes.
NOT APPROVED
WAIT / STOPNo production publication
The flow cannot reach publishing without approval.
APPROVED
PUBLISHPublish versioned static assets
API reference and demo assets are published and claimed with release metadata.
MAVENValidate assets, tag, and publish modules
The published docs assets are verified before Maven credentials and signing are used. Axion creates and pushes the release tag.
DEPENDENT RELEASE WORK
ANDROIDBuild and upload Android release APK
The Android build consumes the newly published stable Maven version.
DEPENDENT RELEASE WORK
DOCSPromote release notes and docs
charts-docs receives the release content, registry entry, and version metadata.
PUBLIC VERIFYDo the manifest and public routes respond correctly?
The workflow waits for deployment and checks the manifest, versioned wiki, API reference, and demo route.
NO · timeout or mismatch
STOPRelease is not announced
The workflow retries for up to 20 minutes, then fails without closing the release loop.
YES
FINISHPublish the GitHub release
Release-note highlights are published and the commit receives documentation and Maven links.
What stays true
Clear checks. Predictable releases.
Each step has a clear purpose and outcome, from the first pull request check to the published release.
Versions stay aligned
Snapshots, documentation, demos, and stable releases use matching version metadata as they move through the ecosystem.
Docs travel with versions
Release notes, API references, demos, and playground assets are promoted alongside the library version they describe.
Checks stay purposeful
Expensive validation runs for meaningful code changes, while optional visual checks remain available without becoming noise.
Keep exploring