Distribution of this plugin has been suspended due to unresolved security vulnerabilities, see below.
The current version of this plugin may not be safe to use. Please review the following warnings before use:
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.
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!
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.
The general format is to use
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.
There are several convenience features for common things such as finding a project. E.g, you can do
To trigger a build of myProject
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:
You can then build those projects in order (stopping if fails occur)
Or even determine if anything within it requires building:
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'.
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...
0.1 : Initial version