Intro
I've started a common_groovy.xml file to set some common functionalities for groovy based builds. It is an ant build file that sets some common options and executes a user selected groovy script. Just recently David Vrzalik added a groovy option to the free-style project type so you can use groovy directly but you'll lack the predefined targets/tasks/properties in the common_groovy.xml file.
Info
The listing below could be out of date, look at common_groovy.xml or ask jboss-qa-internal for what you need.
Some useful groovy variables
File basedir - same as workspace
File configDir - HUDSON_CONFIG_DIR
File staticEnv - HUDSON_STATIC_ENV
See "Globally available classes" below
Some useful project properties accessed by properties\$91'name']
config.dir - same as HUDSON_CONFIG_DIR
static.build.env - same as HUDSON_STATIC_ENV
common.tools - same as COMMON_TOOLS
native.tools - same as NATIVE_TOOLS
source.repo - same as SOURCE_REPO
workspace - same as WORKSPACE
Some ant based targets get imported
get-soa - get SOA Platform binaries
server-config, server-start, server-stop - basic ant tasks to control JBoss AS
As well project basedir is set to job workspace as a workaround to the the weird hudson behavior of setting basedir to the first checkout location
To use it in a real portable way do the following:
Set first checkout location to http://anonsvn.jboss.org/repos/qa/hudson/trunk/scripts/common
Set your project as a second checkout location.
If your project is cvs based that will not be possible. So instead of #1 enable shell script execution and have that there:
cd <first checkout location if using cvs legacy mode or more than one locations>; svn export http://anonsvn.jboss.org/repos/qa/hudson/trunk/scripts/common/common_groovy.xml
Enable ant and set ant options (script is located in the hudson QA repository):
-f common_groovy.xml -Dgroovy.script=scripts/<some.path>/<some groovy script file>
Note: Once we get hudson to expand environment variables, a more straightforward method will be worked out. Though the current one works pretty well.
Globally available classes
Intro
There is a directory $HUDSON_CONFIG_DIR/scripts/groovy.classes (will call it for short classes dir). It is included by default in classpath so any class within is directly accessible. I started that with the QaUtil.groovy having the unzipUrl static method. So you can have in your script "QaUtil.unzipUrl(URL zip, File dest)" and it should work without any include clauses.
This directory can be contructed as a regular classes directory like org/jboss/jbossas/..., but then classes down the hierarchy need to be first included with the include clause before can be used. Probably reasonable for more complicated stuff than the simple QaUtil class.
Lets use QaUtil for simple static helper methods. For other stuff we can always discuss with the team.
Current state
List classes and methods (but not limited to):
- QaUtil
- unzipUrl()
- tokenize()
- NullOutputStream
- WriterOutputStream
- StreamPump
- ShellExec
- EmptyInputStream
Usage:
- look at test directory for available tests
- recursive grep through the scripts in the "scripts" directory (grep -r <Class> <dir>)
- look at the code
Future suggestions
- a good JBoss AS start/stop control not based on the old apache-ant tasks is desirable
- write and generate html javadoc for the classes in the directory
Creating and modifying job without committing:
When creating a job or trying changes it is not always desirable to commit 90 times until job is ok. So see how I temporary change location of the hudson local QA repository until I'm happy with my modifications:
-f common_groovy.xml -Dbits.type=standalone -Dgroovy.script=scripts/soa/jbpm.3/runtests.groovy -Drem.execute.enterprise=true -Denv.HUDSON_CONFIG_DIR=h:\hudson\alexk_config_repository
Relevant here is "
-Denv.HUDSON_CONFIG_DIR=h:\hudson\alexk_config_repository
" As you see you can set other ant properties as well.
Some intro to groovy
Well it's java with a very relaxed syntax. See http://groovy.codehaus.org/Getting+Started+Guide for quick tour. What is a bit frustrating at first is how to get access to ant tasks/targets. To simply execute a target you can 'project.executeTarget("
")'. But you can't use that to execute a single target twice. So you can:
ant.ant( antfile: varFile, inheritAll: 'false', target: "run_tests") { propertyset( refid: "to.inherit" ) }
Another example is:
ant.copy( file: jpdlWrapperPath, todir: jpdlDir.getAbsolutePath(), verbose: "true" );
So you can actually write ant files without the XML stuff + you have a great flexibility to change project options 'project.setProperty("server.name",asConfig);' or "properties[server.name|'server.name']=asConfig". As well read-only properties like these on the command-line 'project.setUserProperty("server.name",asConfig);'. You can see ant and groovy API documentation for more.
As well I found very useful the Properties java class for managing property files.
I recently found useful to create a propertyset and use it for passing options to ant "ant" and "antcall" tasks like:
PropertySet toInherit=new PropertySet(); project.addReference("to.inherit",toInherit); toInherit.setProject(project); toInherit.appendName("user.home"); task.log("to.inherit properties below:"); println toInherit.getProperties(); ant.ant( antfile: jpdlWrapperLoc, inheritAll: 'false', target: "run_tests") { propertyset( refid: "to.inherit" ) }
Keep in mind that property contained properties don't get set as read-only properties for the called project so will not be always passed down to any subsequent ant task like it is with regular properties. For example a read-only property will be set for any task executed through ant/antcall task even if inheritAll is false. So another way is to just project.setUserProperty("prop","val"); and leave inheritance to take place.
One issue to keep track on is quoting. You can single, double and tripple quote with ' and ". Use tripple quotes for multiline strings. Keep in mind no quotes escape special characters so you have to always escape $ for example. With that in mind beware writing regular expressions!
See other differences from JAVA - http://groovy.codehaus.org/Differences+from+Java
Comments