https://github.com/barchart/barchart-jenkins-m2release-plugin/wiki/Algorithm-Flow---Brain-Dump
This brain dump now has me thinking that cascade releasing from the highest level project instead of lowest would be a cleaner and less "magical" solution; when triggering a release of a leaf project, it recursively looks for snapshot dependencies that 1) are the most recent snapshot for an artifact, 2) have no associated release yet and 3) exist as Jenkins jobs. The plugin then triggers releases for these dependencies in the proper order starting from the lowest level, updating to release versions and committing POMs as it goes up the line. This would solve our current dilemma just as well, since with our builds all of the leaf projects are pulled in as dependencies of an "application artifact" for deployment; triggering a cascade release on the application artifact with this method would achieve the same results as the original proposal. Moreover, a failure at any level would not require restarting the build at some arbitrary point in the build tree; you would just start the release again from the same job after fixing any issues. -j On Wednesday, February 27, 2013 11:58:17 AM UTC-6, jeremy....@barchart.com wrote: > > Adding those two goals is a good idea, Keith - I should add them to our > builds as well. Although, I would still have to kick off 15-20 sequential > releases after a core project is updated with a new API I need access to. > > The two use cases we have right now involve single, large parent projects > that have independently-versioned modules - we never do an actual release > of the parent, it is just a container for related subprojects. Some modules > serve as parents or core dependencies for other modules. The modules are > only updated to reference a core snapshot dependency when we are preparing > for a cascade release like this. > > To avoid the "unintended release" scenario, instead of a single "Cascade > release" option, the plugin could display a list of Jenkins jobs it is > aware of that explicitly depend on the snapshot version that is being > released (no ranges, etc), and allow you to check off which ones you also > want to also release (and a "select all" option.) > > Workflow: > > Split all selected projects into different build group levels, which only > depend on projects in previous levels. For example, if two dependency paths > are C -> B -> A and D -> A, the top level build group would contain A (the > original project being released), second level would have D and B, third > level would have C. Then for each level: > > 1) Release all projects in the level > 2) After all projects in the level are released, the next level's POMs > should be updated with any newly-released versions and committed (like you > do with versions:use-releases scm:checkin) > 3) Move on to the next level and repeat > > Basically a bulk version of what you describe, with some intelligent build > ordering so you don't need to manually kick off new builds as previous ones > complete. Release failures can be an issue, but I think as long as they are > clearly noted and only cause a partial tree failure without stopping the > entire process, it is easy enough to see which part of the build tree > failed after the fact and manually restart a cascade release from the > failing node once the issue is fixed. > > Personally, I think it makes more sense in Jenkins than the IDE, since > Jenkins already has the build/release configuration for all projects. > > -j > > On Tuesday, February 26, 2013 9:40:59 PM UTC-6, Keith Collison wrote: >> >> We've put in place the first half of this by adding these goals to our >> maven builds: >> >> versions:use-releases scm:checkin >> >> The former will update a pom to use released versions of snapshot >> dependencies. The latter commits any resulting changes to the pom.xml. We >> also use the "includesList" parameter to limit the release check to our own >> libraries. See this >> page<http://mojo.codehaus.org/versions-maven-plugin/use-releases-mojo.html>for >> info regarding this goal and plugin. >> >> Some caveats to this approach: >> >> 1. If the pom.xml uses a property to define the dependency version (i.e. >> "<version>${defined.elsewhere}</version>"), the versions plugin will not >> update the version. >> 2. The versions plugin only scans the module's <dependencies> list. If >> you have a parent-pom declaration whose version is set to a SNAPSHOT, it >> will not update it. >> >> I'd have reservations, I think, with the exact workflow you've described, >> as it might lead to unintended releases. However, if you started from the >> most-dependent module (i.e. the webapp or application you want to release), >> and then calculated what upstream dependencies needed to be released, that >> would be ideal. Just because I've released some base library upon which 20 >> apps depend does not mean I want to cut a release of those 20 apps. >> >> >> >> >> >> >> On Tuesday, February 26, 2013 1:06:16 AM UTC-5, Andrei Pozolotin wrote: >>> >>> Hello, there! >>> >>> I am curious : "How to better manage cascading releases" >>> for the following use case and what you think about possible solution: >>> >>> ################################# >>> Releasing core bundles and dependent bundles >>> >>> Changing the API of a core bundle for an application requires a rebuild >>> of everything down the line in order to use the new feature. For projects >>> with large numbers of modules (platform, news) this is a very lengthy >>> process of splitting the bundles into dependency phases, then for each >>> phase, releasing a new version of each bundle, updating the next phase's >>> bundles with the newly released versions, and then releasing next phase's >>> bundles, etc, etc. This can be a multiple hour process with Jenkins, >>> compounded by the fact that you can only release one sub-project at a time >>> in a Git repository to avoid push conflicts causing the build to fail. This >>> process occurs much more frequently than I would have originally assumed. >>> Right now I have a bash script that attempts to automate this for news with >>> a combination of the maven release and version plugins, but a better >>> generic solution would be very welcome. >>> >>> *Proposal: Modify Jenkins maven release plugin with the following >>> behavior:* >>> >>> 1. >>> >>> Add a "Cascade release dependent projects" checkbox on release page >>> 2. >>> >>> After the release completes, look for jobs that are explicitly >>> dependent on the pre-release snapshot version >>> 3. >>> >>> Update these dependent modules with the newly release version, and >>> trigger a Maven release on them as well >>> 4. >>> >>> Failing releases should be skipped, and then trigger a build failure >>> at the very end, with clearly noted messages as to which sub-tree failed >>> so >>> the user can check the logs and manually cascade release the subtree >>> >>> Step c) would need some cycle detection to support scenarios where B and >>> C depend on A, but C also depends on B - both A and B would have to be >>> released before C could be released. >>> ################################# >>> >>> Thank you, >>> >>> Andrei >>> >>> -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
