maven-release-plugin : How to better manage cascading releases

[Andrei Pozolotin]

                  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

[Jeff]

I've thought about this too, there could be a logistics issues with how/where to find the dependent projects unless you have a multi-module POM (parent + children) or some other way to either tell it where to find the dependencies or impose a rigid project/folder structure.

I wonder if this type of behavior (cascading releases) should be part of a build tool like Jenkins or an IDE plugin since these types of tools likely already have the knowledge of needed dependencies.

--
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-use...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Jeff Vincent
preda...@gmail.com
See my LinkedIn profile at:
http://www.linkedin.com/in/rjeffreyvincent

I ♥ DropBox !! 

[Keith Collison]

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 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.

[Andrei Pozolotin]

Jeff: thanks for the feedback. Andrei.

You received this message because you are subscribed to a topic in the Google Groups "Jenkins Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-users/4OZsB9LV6nE/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to jenkinsci-use...@googlegroups.com.

[Andrei Pozolotin]

Keith: very good points, thank you very much for sharing. Andrei.

-------- Original Message --------
Subject: Re: maven-release-plugin : How to better manage cascading releases
From: Keith Collison <ke...@vervewireless.com>
To: jenkins...@googlegroups.com

[Andrei Pozolotin]

Jeff, Keith: would you be interested in collaborating on a jenkins plugin for this? Andrei.

-------- Original Message --------
Subject: Re: maven-release-plugin : How to better manage cascading releases
From: Keith Collison <ke...@vervewireless.com>
To: jenkins...@googlegroups.com
Date: Tue 26 Feb 2013 09:40:59 PM CST

We've put in place the first half of this by adding these goals to our maven builds:

[jeremy....@barchart.com]

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

[jeremy....@barchart.com]

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

[Andrei Pozolotin]

Jeff, Keith, Jeremy:

so it seems we have few different use cases in mind between us.

it would probably help if we create 2-3 mock repositories on github

to emulate our most interesting use cases.

what do you think?

Andrei.

[Jeff]

Does github have a maven repository?

--
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-use...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Jeff Vincent

See my LinkedIn profile at:
http://www.linkedin.com/in/rjeffreyvincent

I ♥ DropBox !! 

[Stephen Connolly]

https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide

Please don't host your own maven repositories on an SCM

[Jeremy Jongsma]

I assume he is referring to Git repositories, not Maven repositories, for hosting a set of mock projects with inter-dependencies that are representative of our use cases.

Andrei, if you have a repository available, please grant me access and I'll be happy to contribute a use case example.

-j

You received this message because you are subscribed to a topic in the Google Groups "Jenkins Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-users/4OZsB9LV6nE/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to jenkinsci-use...@googlegroups.com.

[Jeff]

I would guess we would likely want/need both, unless there is a way to tell Maven to "deploy" snapshot or release artifacts only to the local repository.  If it is possible, I don't know how to do that.

[Andrei Pozolotin]

Jeff, Jeremy:

you are right, we need both.

1) here is git repo for project layout use cases
https://github.com/barchart/barchart-jenkins-tester

2) for maven, I assumed we can use our respective private repository
"distribution" settings as defined by our settings.xml.

for example, when you run theses tests
https://github.com/barchart/barchart-jenkins-m2release-plugin/tree/master/src/test/java/org/jvnet/hudson/plugins/m2release

they build and fire up your local jenkins with plugin inside, which will use your local .m2/settings.xml

alternatively, we can setup shared maven repo on Amazon S3 or CloudBees@DEV

Thank you,

Andrei

-------- Original Message --------
Subject: Re: maven-release-plugin : How to better manage cascading releases
From: Jeff <preda...@gmail.com>
To: jenkins...@googlegroups.com

[Andrei Pozolotin]

Stephen

OK! We won't! :-) Thank you,

Andrei

You received this message because you are subscribed to a topic in the Google Groups "Jenkins Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-users/4OZsB9LV6nE/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to jenkinsci-use...@googlegroups.com.

[Andrei Pozolotin]

update:

1) extending maven-release-plugin / jenkins m2release by itself,
http://maven.apache.org/maven-release/maven-release-plugin/
https://wiki.jenkins-ci.org/display/JENKINS/M2+Release+Plugin
will not work - need orchestration plugin.

2) cascade orchestration plugin is here, 30% done:
https://github.com/barchart/barchart-jenkins-cascade-plugin

3) proposed target project family repository layout is here
https://github.com/barchart/barchart-jenkins-tester

feedback & code review is appreciated.

-------- Original Message --------
Subject: Re: maven-release-plugin : How to better manage cascading releases
From: Jeff <preda...@gmail.com>
To: jenkins...@googlegroups.com
Date: Thu 28 Feb 2013 12:20:14 PM CST

I would guess we would likely want/need both, unless there is a way to tell Maven to "deploy" snapshot or release artifacts only to the local repository.  If it is possible, I don't know how to do that.

[Andrei Pozolotin]

Jeff, Jeremy:

update:

1) I released first version of the the plugin.
https://github.com/barchart/barchart-jenkins-cascade-plugin/wiki

2) see if you can make sense out of it.

3) please file issues
https://github.com/barchart/barchart-jenkins-cascade-plugin/issues
and improve documentation
https://github.com/barchart/barchart-jenkins-cascade-plugin/wiki

Thank you,

Andrei