Continout Integration : Github, S3, maven releases, no SNAPSHOT required.

this is howw u doooo it …….

The maven release:prepare plugin can be very powerful if you follow maven guidelines, but some projects choose not to follow maven guidelines.

I’m not sure why anyone in the universe would EVER use maven without following the conventions… But some people do.

In any case: Ideally in a CI environment, we’d like to see:

– code is pushed
– code is tested
– if passed, version is incremented
– the new version is released into a mvn repository and tagged

The first two steps can be done in any CI that supports maven.   What about the second two ?

Well, if you are using SNAPSHOTs, you can easily do the tagging in one step :

mvn release:prepare

And then do the deployment of the prepared release like this:

mvn release:perform

This command conveniently (when combined with the necessary SCM tags) checks that your head is clean, increments the SNAPSHOT version, and prepares a release pointing to the ceiling of your previous snapshot.

Here’s what to do if somebody tells you that your NOT ALLOWED to use SNAPSHOTS

complain: First, complaint that its ridiculous not to use SNAPSHOT versions for maven development.  Almost every mature maven project uses snapshots, and the maven ecosystem is in many ways build around the concept of having the SNAPSHOT in the version string.

After your complaints are not heeded, write a python script like this: 

import sys

”’
  example: python version_incrementer.py 1.2.3
  input: A version string (i.e. “1.2.3”)
  output: Writes incremented version to std out ( “1.2.4”)
”’

v1 = str(sys.argv[1])

v1List = v1.split(‘.’)

v2 = str(v1List[0])+”.”+str(v1List[1])+”.”+ str(int(v1List[2])+1)
print v2;

And then use it like this (implement the first line of pseudo code however you need to, basically you want to make sure you dont create an infinite loop where the version auto increment triggers a new build each time).

    if `git log -1` ! contains “ci-skip“:

          
    version=$(mvn org.apache.maven.plugins:maven-help-plugin:2.1.1:evaluate -Dexpression=project.version | grep -v “\[“)

newversion=$(python /tmp/version.py $version)

mvn versions:set -DnewVersion=$newversion

git add pom.xml

git commit -m “$newversion auto commit [ci-skip]”

git tag -a ‘$newversion’ -m “Auto increment version $newversion”  

git push –follow-tags 

The above script will : parse your maven version , increment it, and commit the pom back into git for you.

Great…. So you can auto increment the versions.  But how do I glue this into my CI so that the jars are released with the NEW version and not the old one?

First quickly scan this example of how to setup maven to deploy to FTP (even though we’re using s3) : http://maven.apache.org/plugins/maven-deploy-plugin/examples/deploy-ftp.html.  The above is a “textbook” example of the three components to maven deployment : the releaseManagment, server settings configuration, and build extensions.  In our case, we use s3, but these still all need to be set.

HEre’s a simple way (probably not the best) Normally, git commits will result in a build.
Let that build occur (just package the jar), up until deployment as normal.

Now, if the build passes, you can run the bash script above afterwards.  Then, go back to maven and run its “deploy” goal.  This time, we’ll skip the tests since we already ran them…

         mvn deploy -DskipTests=true

What does “deploy” do?  It deploys the jars.  So, before you run it — lets set up s3 deployment parameters.

One last trick : Deploying to S3. 

While we are at it, lets just cover the basics of s3 publishing in maven.

First, you want to put your maven credentials into your pom.  These should go in the top level (i.e. right under your pom’s top level <version></version> tags).

 <distributionManagement>
                <repository>
                        <id>maven-s3-release-repo</id>
                        <name>S3 Release Repository</name>
                        <url>s3://bigpetstore/maven</url>
                </repository>

</distributionManagement>
<scm>                 <connection>scm:git:git@github.com:jayunit100/bigpetstore.git</connection

<url>scm:git:git@github.com:jayunit100/bigpetstore.git</url>
                <developerConnection>scm:git:git@github.com:jayunit100/bigpetstore.git</developerConnection>
          <tag>HEAD</tag>

     </scm>

Then, under the <build> tag, add in the aws release extension:

         <extensions>
          <extension>                                 
                     <groupId>org.springframework.build.aws</groupId>                    <artifactId>org.springframework.build.aws.maven</artifactId><version>3.0.0.RELEASE</version>
          </extension>
    </extensions>

Finally, put your S3 credentials into your maven settings.xml file.  There are alot of easy to follow posts on how to do this online.  The file is either found either in $M2_HOME/settings.xml, or somewhere such as /usr/share/maven/conf/settings.xml.   Play around with it a little to make sure its the “right” settings.xml file !

Summary

We just walked through setting up a continuous integration framework that auto increments releases using raw “mvn” and “git tag” commands, with a little python number crunching, all wrapped up in a tidy bash script.   Then, we outlined how to add in the aws.maven plugin above to use your s3 credentials to deploy maven files if your distributionManagement points to an s3:// url, as I exemplified above.