Relates to Trunk-Based Development (I maintain https://trunkbaseddevelopment.com) . Some of my clients do "branch for release". Every cherry pick from trunk to the release branch (bug fix) would wake up Jenkins. By default that'd do a full build and then artifacts get pushed into artifactory/nexus and from there a deployment into UAT - bouncing whichever services have been changed.
The build pass/fail gate will fail though, *if* the versions (in the POMs) have been published already - Nexus/Artifactory will correctly object. What I want to do is effect a system that *only the changed modules *will be blocked on a second publication attempt. Unchanged ones will be skipped for publication. Say there were 100 modules (services, applications, their deps) that the build would compile/test. If there were a bug fix to just one module, I would want Jenkins to note the failing publication attempt for that one only. If builds are reproducible (hard for Maven I realize *) then the SHA-1 of the binary can guide whether it needs to go to the remote repo or be skipped. The pseudocode covers that. The release engineer would then change *one* POM version (say 4.3.0 to 4.3.1) in the release branch, commit, Jenkins is triggered, full build - but only one changed item gets pushed up to the remote binary repo - to a new GAV - and all others are skipped. "Branch for release" within trunk-based development is just one way of working and suits a range of release cadences for teams. * https://maven.apache.org/guides/mini/guide-reproducible-builds.html - Paul
