cap-java-child

The consumer side of a promotion model for CAP Java: a parent pom pinned to a fixed version, Renovate opening the bump as a pull request, the application's own tests as the gate, and auto-merge only on green.

A shared library's version bump has to reach every application that depends on it, and this removes the manual check at each one: cap-java-parent-pom-samplecap-java-parent-pom-samplesampleA Maven parent pom published to GitHub Packages that pins cds-services-bom, the Spring Boot BOM and a shared CAP Java plugin, so a child application names the parent coordinate and no versions of its own.independent, cap publishes central-parent at a fixed version, Renovate watches that coordinate on GitHub Packages and opens the <parent> bump as a pull request, and the application's own mvn test decides whether it merges. Three traps are documented: the required status check is the job name test, not the step or the workflow name, and it only reaches the branch-protection picker once the workflow has run; Renovate does not read settings.xml, so renovate.json names the GitHub Packages registry and its token itself; and one read:packages token is registered twice, as a Mend secret for Renovate and an Actions secret for the build. When the library changes its contract the guide puts the test fix on the Renovate branch, because the parent bump alone is red and the test fix alone is red and only the two together merge. The pull-request gate is GitHub Actions and the deployment pipeline is SAP CI/CD on a webhook from main, kept apart on purpose. Written in Japanese.

Who is behind it

Mio YasutakeMio YasutakePersonMaintains this
In the atlas: maintains 47, contributes to 47, wrote 10@miyasutamaintainer