Jenkins Adaptive Plugin

Skip to end of metadata
Go to start of metadata

Plugin Information

Plugin ID AdaptivePlugin Changes In Latest Release
Since Latest Release
Latest Release
Latest Release Date
Required Core
Dependencies
0.1 (archives)
Mar 03, 2011
1.398
Source Code
Issue Tracking
Pull Requests
Maintainer(s)
GitHub
Open Issues
Pull Requests
Nigel Magnay (id: magnayn)
Usage Installations 2014-Jun 148
2014-Jul 153
2014-Aug 160
2014-Sep 170
2014-Oct 160
2014-Nov 162
2014-Dec 165
2015-Jan 159
2015-Feb 171
2015-Mar 165
2015-Apr 161
2015-May 163

This (experimental) plug-in exposes the jenkins build extension points (SCM, Build, Publish) to a groovy scripting environment that has some DSL-style extensions for ease of development.

Description

Sometimes when using Jenkins, one comes across the situation whereby the system doesn't /quite/ do what you want it to, and you need to extend a particular plugin in order to get something done. There are occasions where you want this to be done inside the SCM - either for doing multiple checkouts, or in responding to the 'is this job requiring a new build' trigger, sometimes as a build step, and sometimes as a post-build, publishing action.

The adaptive plugin is similar to the groovy plugin and groovy post build in that it is scripted using groovy. However, it has a number of differences. 

Firstly, the script is stored in one place in the project - so if you have elements that are invoked at different phases, they are visible next to each other in the script.

Secondly, the script can bind to the SCM stages of the build

Finally, the script uses a DSL in order to try to simplify access to particular hudson resources. However, this is still experimental!

Example Script

jenkins {
  scm { 
    poll {    PollingResult.BUILD_NOW  }
    checkout { 
        checkout GitSCM("git.repo.url":"git://github.com/magnayn/Ribbons.git",
                        "git.repo.name":"origin",
                        "git.repo.refspec":"",
                        "buildChooser":[ "stapler-class":"hudson.plugins.git.util.DefaultBuildChooser" ] );      
     }  
  }  


  build { 
     println "Trying to build";     
     invoke Maven( rootPOM:"pom.xml",
                   targets:"clean install"     );  
  }  


  publish {
       def ab = new AntBuilder();       
       ab.taskdef(name: 'scp', classname: 'org.apache.tools.ant.taskdefs.optional.ssh.Scp');       
       ab.scp(file:"/tmp/file.txt", todir:"repo:repo@internalrepo:/home/repo" );  
  }
}

}

This script tells Jenkins every time it asks that 'yes, I need to build now'. It calls Git to check out the code, Maven to invoke the build, and finally utilises the AntBuilder to SCP it to a remote server.

Calling plugins

The general format is to use

invoke <pluginName>( <pluginParameters> )

The parameter names are those that would have been returned by the web (stapler) page. However - these are not particularly exposed for end-users, so some sourcecode digging is sometimes needed.

Utility functions

There are several convenience features for common things such as finding a project. E.g, you can do 

build project("myProject")

To trigger a build of myProject

Build Chains

One of the experimental ideas in the plugin is one of build chains - that you can specify an ordered set of builds to be done:

def chain = project("test") >> [project("test2"), project("test3")] >> project("test4")

You can then build those projects in order (stopping if fails occur)

build chain

Or even determine if anything within it requires building:

jenkins {
  def chain = project("test") >> [project("test2"), project("test3")] >> project("test4")
  scm {
    poll { poll chain; }
  }
}

The 'chain' functionality is an (unfinished) idea whereby you may wish that if there is a projectA, build it and all the downstream builds; then IF and ONLY IF they are all successful, then commit that change to the main branch in the SCM. This allows a 'master project' to give the illusion of atomic commits, even if it is comprised of multiple, disparate repositories. So, for example, your developer commit to branch 'dev' may trigger a chained build. If the build of the project is successful (individually), then the commit is promoted to 'master'. If the full chained build (including downstream integration tests), then it is additionally promoted to 'release'.

Caveats:

This is still a work-in-progress;

When it fails (particularly using hpi:run rather than a full jenkins install) the classloader seems to explode in interesting ways...

Version History

0.1 : Initial version

Source Repository

git://github.com/magnayn/Jenkins-AdaptivePlugin.git

Labels

Edit
plugin-misc plugin-misc Delete
plugin-buildwrapper plugin-buildwrapper Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Add Comment