IKE Tooling
IKE Maven Plugin 234
-
Home
- Overview
The IKE Release Cascade
The IKE foundation is three repositories that must release in topological order, because each consumes the artifacts of the ones above it:
ike-tooling → ike-docs → ike-platform
ike-docs and ike-platform declare ike-maven-plugin — and consume ike-build-standards — through ${ike-tooling.version}; ike-platform also consumes ike-docs through ${ike-docs.version}. A downstream repo released against a stale upstream pin ships a split foundation. The release cascade is the machinery that keeps the three coherent.
Unresolved directive in <stdin> - include::_cascade/cascade-model.adoc[]
The goals
ike:release-publish — one repo, upstream-aligned
Before cutting a release, ike:release-publish reads the repo’s own release-cascade.yaml and, for every upstream edge, resolves the latest released version of that upstream and bumps the edge’s version-property when the POM is behind. A single-repo release is therefore correct on its own — it can never ship on a stale foundation.
The preflight fails on any warning by default; pass -Dike.release.ignoreWarnings=true to release past warnings (errors are never ignorable). See IKE-Network/ike-issues#428.
ike:release-cascade — the executor
Walks the whole cascade. Run from any foundation repo (with the others checked out as siblings); it assembles the graph, walks it in topological order, and runs ike:release-publish on every repo that has unreleased changes — skipping repos whose only commits since their last tag are release-cadence bookkeeping.
mvn ike:release-cascade # release the cascade
mvn ike:release-cascade -DpushRelease=false # local-only walk
mvn ike:release-cascade -Dike.release.cascade.basedir=/path/to/checkoutsike:cascade-export — the topology
Assembles the graph and writes it as JSON or .properties — the input a CI meta-runner consumes to generate build-chain edges instead of hand-wiring them (IKE-Network/ike-issues#403). Read-only.
mvn ike:cascade-export # JSON to stdout
mvn ike:cascade-export -Dformat=properties
mvn ike:cascade-export -DoutputFile=target/cascade.jsonTesting the cascade safely
Both inspection paths are side-effect-free, so the cascade can be exercised at any time:
mvn ike:cascade-export— proves the per-project manifests assemble into a valid, ordered graph.mvn ike:release-cascade -DpushRelease=false— walks every repo and reports its state. When the foundation is freshly released, every repo reports up to date and nothing is released:
Foundation release cascade — 3 repo(s) in order: ike-tooling → ike-docs → ike-platform
─── ike-tooling ─── At v183; no meaningful commits since — skipping (already released).
─── ike-docs ─── At v40; no meaningful commits since — skipping (already released).
─── ike-platform ─── At v66; no meaningful commits since — skipping (already released).
Cascade summary:
— up to date ike-tooling (v183)
— up to date ike-docs (v40)
— up to date ike-platform (v66)Running a real cascade
Check the three foundation repos out as siblings under one directory, then run ike:release-cascade (or use the IntelliJ run configuration of the same name) from any of them. The executor releases each repo that has changes, in order, so each repo’s Nexus deploy completes before the next — which ike:release-publish then aligns to the just-released upstream — begins.
CI / TeamCity
The documented CI model runs one build configuration per foundation repo, with TeamCity — not ike:release-cascade — orchestrating. The build-chain edges are generated from ike:cascade-export; because the assembler falls back to cloning from each edge’s url, the export runs on a bare CI agent that has only one repo checked out.
Related
IKE-Network/ike-issues#420— the decentralized per-project model.IKE-Network/ike-issues#419— theike:release-cascadeexecutor and per-repo upstream alignment.IKE-Network/ike-issues#428— fail-on-warnings release preflight.IKE-Network/ike-issues#429— URL-mode cascade resolver.- ike-maven-plugin goal reference[1].