Hi, Typing this out on my phone so apologies if it doesn't make sense :)
Not sure how to help with the groovy setup, but was trying to understand why you need the complex groovy script. >From what I understand your main build produces 2 war files, I assume they have a maven version in the name and perhaps a build number so the name of the wars may change. I have not used the deploy plugin but from what I have read it will let you specify multiple files to deploy by using *.war but only to one tomcat server? Do you need both files deployed to both tomcat servers, or one file to one server and the other file to the second server? My initial thoughts are: 1. main build job would archive both the Wars as artifacts 2. Deploy to server 1 job: use the Copy artifacts plugin to copy the artifacts from main build job to the workspace of deploy job 1. This doesn't need the name of the files. it can copy all or use wildcards to filter files. Then use the deploy plugin to deploy wars to server 1. 3. Deploy to server 2 job would be similar but deploy to server 2... Geoff On 27 Mar 2013, at 03:20, Scott Ellis <[email protected]> wrote: I've been working on this for two days and have googled this to death. There are just too many unknowns for me and I need some help. The original problem I'm having is that I want to deploy two war files from a multi-module maven project, and Jenkins is only giving me the option to deploy one--I'm deploying to two different tomcat containers. So I decided to trigger two different deployment jobs to get it done instead. The problem became: what is the actual name of the war file, including the version? This isn't easily available. I found a post on how to acquire the name from the generated pom, which wasn't perfectly in line with my set up, but useful. The concept requires that I call a post-build groovy script, that must be run as a system script so that I can acquire variables in context of the build environment. So I do this, but the script requires that I add to the classpath some third-party jars. So long story short, the script will run fine as I'm testing it locally, but my build declares a slave node upon which this script must run. Only the master node has this groovy environment set up correctly, and I need Jenkins to transfer my deployment to the slave. I found this<http://jenkins.361315.n4.nabble.com/Installing-build-tools-on-slaves-in-clustered-Jenkins-environment-td3636863.html>thread, with this reply that I found interesting: Our shop gets around this by using the "Run SSH command on slave" option to > start our slaves, and specifying a shell script that rsyncs a tools > directory from the master to the slave before starting the slave process. > The master tools directory contains the JDK plus all the tools we need > such as Ant, Maven, Groovy and so on. This has the added advantage that we > can push tool updates out to all the slaves by just updating the master > directory and restarting the slaves. This I think would solve my issue, but I am a rookie Linux user and do not know much about his subject. Some, but not enough. I would love it if someone could explain to me how to get my groovy installation to the slave node. I know there is an option to install automatically, which I've attempted, but I don't see anything. Where does it go if it works? My build slave node home appears to be at /Users/Shared/Jenkins/Home/jenkins-slaves/build-slave (build-slave being the name I've assigned it). I'm good right now with simply copying my groovy installation onto the slave node, but where should it go? I tried tarring the installation, complete with my modifications to groovy-starter.conf, which adds the third-party libraries needed by the new script. In the groovy configuration I've configured groovy to install automatically, and I chose the extract *.tar.gz option and specified with a file-style url the tar file. It's lame, but that's what I've tried. Groovy runs during the build, but I'm getting class not found errors because my third party jars are not being found. I hope someone can point me in the right direction. Thanks, Scott -- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out. -- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
